This forces .generator_object variable to stack slot 0 for async
generator functions so that the stack trace construction logic
can extract the JSAsyncGeneratorObject appropriately.
Bug: v8:7522
Change-Id: I37b52836bb512bcf5cd7e10e1738c8e7895b06ea
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264556
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56415}
GCC 4.9.2 on MIPS generates a reference to OFStreamBase()
d8.cc. In debug mode OFStreamBase is local to libv8_base and
linking fails.
Change-Id: I93bb93d03a4cc81c59f94cf2168c92557845e87d
Reviewed-on: https://chromium-review.googlesource.com/c/1258903
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#56413}
For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.
Some drive-by cleanups:
- Remove the switch in NameForRuntimeId() and just use the table of
runtime functions to lookup the name directly.
- Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
they are the last users of the inline versions of these.
- Remove the MaxSmi inline version as it is only used in tests.
Saves 64 KiB binary size.
Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
This changes TurboFan to treat SignedSmall feedback similar to Signed32
feedback for binary and compare operations, in order to simplify and
unify the machinery.
This is an experiment. If this turns out to tank performance, we will
need to revisit and ideally revert this change.
Bug: v8:7094
Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
Reviewed-on: https://chromium-review.googlesource.com/c/1261442
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56411}
This cuts down the perf cost on Octane from 18% to 13%. The baseline is the no mitigation
Octane score, the array access mitigation cost was about 4%. This means we would be
getting a bit more than 1/3 of the poisoning regression back.
Bug: chromium:856973, chromium:887213
Change-Id: Ibd99f66ae832c6080f2c2e5b33a1a7610907466f
Reviewed-on: https://chromium-review.googlesource.com/c/1251401
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56409}
Move the entry-point for destructuring assignment out of the recursion so we
can avoid swapping ASSIGNMENT scope to ASSIGNMENT_ELEMENT.
Also rewrite Assignment directly without wrapping in RewritableExpression
first.
Change-Id: Iae768ad1b2a6fb40ce37142867d7034f924354e4
Reviewed-on: https://chromium-review.googlesource.com/c/1264284
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56406}
After rewriting a rewritable assignment expression we possibly add the
resulting do-expression in two places: the rewritten expression and the parent
block. That would observably generate duplicate code. Luckily this can't happen
since the only recursive paths that would call this function again change the
context to ASSIGNMENT_ELEMENT from ASSIGNMENT. Hence simply DCHECK_NULL(block_)
and reset it to nullptr at the end.
Change-Id: I17b84dedcd7daf800d9ccb90e3dd975e84b12717
Reviewed-on: https://chromium-review.googlesource.com/c/1264282
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56404}
var declarations that walk through with scopes are special in that the variable
will always end up in the outer declaration scope, but the initializer for the
var will possibly target the with scope. Hence we can't simply use the resolved
variable proxy from the declaration for the initialization. However, if we know
that the var declaration lives in the scope where it will be declared (the
common case), there can't be a with scope in between. Hence we are free to
reuse the proxy.
Change-Id: I434abcd5df1a44313a8b8da3303cf5748299de4b
Reviewed-on: https://chromium-review.googlesource.com/c/1261450
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56403}
When parsing an identifier as an expression we'll immediately create an
unresolved VariableProxy in the parsing scope. If this variable ends up
becoming a declaration, e.g., due to arrow function parameter, we'll move it
into the function scope for that arrow function. Then to actually create the
declarations we rewrite the "pattern". When we declare the variable, the proxy
is automatically resolved to the variable we create from it. That means it
can't be in the unresolved list anymore.
We tried to remove the unresolved variable. Unfortunately, if there was a
sloppy eval in a parameter context, there's an additional var-block scope
created for the parameter. Rewriting happens in *that* scope. Hence we didn't
always manage to remove the unresolved variable. I suppose as a fix an
additional variable proxy was introduced; since otherwise the implicit
resolution upon declaration would trigger a dcheck in scope resolution later.
This CL removes the initial variable proxy from the correct scope, so it can be
reused for the declaration.
Change-Id: Id917afb177aef076a2947b0fdd03b5393bd29c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1261937
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56402}
These functions got replaced the the taskrunner API. The new way to
post tasks is as follows:
v8::Platform* platform = ...; // e.g. V8::GetCurrentPlatform();
v8::Isolate* = ...;
std::shared_ptr<v8::TaskRunner> taskrunner = platform->GetForegroundTaskRunner(isolate);
std::unique_ptr<v8::Task> task = ...;
taskrunner->PostTask(std::move(task));
R=ulan@chromium.org
Bug: v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I44a70fc530daae581ee31e54fd09e776ba648406
Reviewed-on: https://chromium-review.googlesource.com/c/1261936
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56400}
- Get rid of an unnecessary call to uloc_canonicalize in js-locale.
- Do not use regex, but rely on ICU for the structrural validity check
with Chrome's ICU or ICU 63 or newer. Otherwise, continue to use regex.
This became possible thanks to a couple of bug fixes in ICU ToT that
were cherry-picked for Chromium's ICU.
Not yet done is to change js-locale to use CanonicalizeLocale().
That will make a few more tests pass.
Bug: v8:8135
Test: test262/intl402/Intl/getCanonicalLocales/*
Test: test262/intl402/Locale/*
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I45c10b298fb041e0b39a4d96309c68a7966f91c2
Reviewed-on: https://chromium-review.googlesource.com/c/1215223
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56399}
For --async-stack-traces don't try to peak into frames that don't belong
to async functions/generators, specifically don't try to peak into some
arbitrary builtin frames (the FrameInspector doesn't support that).
Bug: chromium:892472, chromium:892473, v8:7522
Change-Id: Idcdee26ff958c03b24dd2910bb92fc51cbc14e3c
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264276
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56396}
The CheckSmi in String.fromCodePoint() is unnecessary and even leads to
unnecessary deoptimizations, since the CheckBounds already does the
right thing, plus it also handles HeapNumbers (in Signed32 range) and
properly identifies zeros.
Bug: v8:8238
Change-Id: I73bf7a70c3cd718c987f112ceb928188c0534cd5
Reviewed-on: https://chromium-review.googlesource.com/c/1262675
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56395}
Remove -Wexit-time-destructors warnings which triggered when global
objects cause destructors to be run at exit time.
Bug: v8:8257
Change-Id: I8407f1936cd6d13a2e30f55cfb4907a99ccca033
Reviewed-on: https://chromium-review.googlesource.com/c/1259863
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56388}
Long time ago there were two passes over heap. One was counting
objects and edge and another was filling them. Since then we have
just a single pass, but the filler object is still there.
Remove it for the sake of layering simplicity.
Reviewed-on: https://chromium-review.googlesource.com/1244380
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56246}
TBR=ulan@chromium.org
Change-Id: Ie155a79f7aaf9b2612ae89f67b793ba813c364c9
Reviewed-on: https://chromium-review.googlesource.com/c/1261882
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56387}
Port b048c16b4f
Original Commit Message:
The goal is to remove CL to remove the confusing implications for
full poisoning.
This is an alternative to
https://chromium-review.googlesource.com/c/chromium/src/+/1253341
where chrome has to work around our implication system.
In the optimizing compiler, we already have a bottleneck for setting
mitigation level in src/compiler/pipeline.cc, so it is easy to change
back to partial mitigations.
R=jarin@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I96d0651eed2638abddb5486da1e2b55a84e97264
Reviewed-on: https://chromium-review.googlesource.com/c/1261797
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56385}
Holes in double arrays are encoded using a signaling NaN bit pattern.
Previously when checking for Float64 holes we did an expensive bit
check always, but most values aren't even NaNs in reality. So we changed
the CheckFloat64Hole operator to first check if the value is a NaN at
all and only if so, perform the concrete bit check (in deferred code).
This improves the array copying test case mentioned in the bug from
copyPacked: 123 ms.
copyHoley: 157 ms.
to
copyPacked: 122 ms.
copyHoley: 125 ms.
so there's almost no penalty for double holey arrays anymore in case of
copying arrays. This change seems to yield an overall ~1% on the Kraken
benchmark.
Bug: v8:8264
Change-Id: Id7393867ec96fdc080e24d326039f80a9d7b6646
Reviewed-on: https://chromium-review.googlesource.com/c/1261519
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56380}
AtomicPair operations are only available with some instructions
introduced in version R6. Add support for needed instructions.
Change-Id: I808d6ed5b5efafd638846ec599941ebc71d90e23
Reviewed-on: https://chromium-review.googlesource.com/c/1251526
Reviewed-by: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#56379}
We want to replace all uses of CallOnForegroundThread eventually by the
new TaskRunner API so that we can eventually deprecate the old API and
remove it.
R=ulan@chromium.org
Bug: v8:8238
Change-Id: I7e451eddf05f1f7f273c5cfd57d82737380f3f02
Reviewed-on: https://chromium-review.googlesource.com/c/1261145
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56378}
This makes it more explicit what we're actually parsing and allows us to omit
unnecessary checks.
Change-Id: I3e22ab4af0f23cee51cb689dd6377565e42f9bad
Reviewed-on: https://chromium-review.googlesource.com/c/1260943
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56377}
Use Check rather than if peek() + Expect/Consume
Change-Id: I5bc98288a751234117a2708c17dbb68008af5838
Reviewed-on: https://chromium-review.googlesource.com/c/1261144
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56376}
We want to replace all uses of CallOnForegroundThread eventually by the
new TaskRunner API so that we can eventually deprecate the old API and
remove it.
R=leszeks@chromium.org
Bug: v8:8238
Change-Id: I6a1e55fe431225ffe4c77cd3387f3b060eb43edf
Reviewed-on: https://chromium-review.googlesource.com/c/1256866
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56375}
The goal is to remove CL to remove the confusing implications for
full poisoning.
This is an alternative to
https://chromium-review.googlesource.com/c/chromium/src/+/1253341
where chrome has to work around our implication system.
In the optimizing compiler, we already have a bottleneck for setting
mitigation level in src/compiler/pipeline.cc, so it is easy to change
back to partial mitigations.
Bug: chromium:888892
Change-Id: I01de7ed7bb91e8b06f8f79cc2d90657a0600892a
Reviewed-on: https://chromium-review.googlesource.com/c/1252985
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56374}
This had bit-rotten a little and did no longer work for compiling
webassembly code. Also, correct the output of live ranges so that it
can be parsed again.
Bug: v8:8238
Change-Id: I09c2d8bd604f3be12ead8b968f0b70287fad65f1
Reviewed-on: https://chromium-review.googlesource.com/c/1256864
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56373}
For NumberModulus and SpeculativeNumberModulus there's no observable
difference between 0 and -0 for the right hand side, since both of them
result in NaN (in general the sign of the right hand side is ignored
for modulus in JavaScript). For the left hand side we can just propagate
the zero identification part of the truncation, since we only care about
-0 on the left hand side if the use nodes care about -0 too.
This further improves the Kraken/audio-oscillator test from around 67ms
to 64ms.
Bug: v8:8015, v8:8178
Change-Id: I1f51d42f7df08aaa28a9b0ddd3177df6b76be98c
Reviewed-on: https://chromium-review.googlesource.com/c/1260024
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56372}
This is a follow-up cleanup to treat NumberRound like the other rounding
operations (NumberFloor, NumberCeil and NumberTrunc).
Bug: v8:8015
Change-Id: I2b2fbc7f0319497d16ccb7472595eeb68be1f51d
Reviewed-on: https://chromium-review.googlesource.com/c/1260403
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56371}
The slow-path of CheckedInt32Mod(x,y) when x is found to be negative
still had the power of two right hand side optimization, and thus would
perform a dynamic check on y. Now the same dynamic check was done for
the fast-path, and the word operations for this check were pure, leading
to weird bit materialization in TurboFan (due to sea of nodes). But
there's not really a point to be clever for the slow-path, so we just
insert the Uint32Mod operation directly here, which completely avoids
the problem.
This improves the Kraken/audio-oscillator test from around 73ms to 69ms.
Bug: v8:8069
Change-Id: Ie8ea667136c95df2bd8c5ba56ebbc6bd2442ff23
Reviewed-on: https://chromium-review.googlesource.com/c/1259063
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56370}
When converting a Signed32\/MinusZero value from Word32 to Float64
representation or just passing it through as Word32 (with potential
type checks on it) we don't need to worry about -0 as long as the uses
identify 0 and -0.
Drive-by-fix: Fix the CheckChange() helper in the representation
changer test to pass Truncation::Any() by default.
Bug: chromium:891639, chromium:891612, chromium:891627, v8:8015, v8:8178
Change-Id: I06948ec0cdb8e778cb3678124ef927277a5f40ee
Reviewed-on: https://chromium-review.googlesource.com/c/1258902
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56369}
Adds new VisitModes VISIT_ALL_BUT_READ_ONLY and
VISIT_STRONG_FOR_SERIALIZATION.
GC-related methods like MarkReachableObjects now now use
VISIT_ALL_BUT_READ_ONLY instead of VISIT_ALL. All GC-related VisitModes
skip iterating over the read-only roots.
All Serializer methods should always use a _FOR_SERIALIZATION value to
ensure they do visit the read-only roots.
Also adds RootsTable::read_only_roots_begin and end methods.
Bug: v8:7464
Change-Id: I468d7ae9f345d9fc0e10837f01dc5b92bd996412
Reviewed-on: https://chromium-review.googlesource.com/c/1256245
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56368}
Often, tasks just need to call a single API method. By implementing
such tasks via a lambda, we save a lot of boilerplate. Additionally,
since lambdas are defined inside other function bodies, they have
access to private methods, which sometimes allows for better
encapsulation.
This CL introduces {CancelableLambdaTask} and
{CancelableIdleLambdaTask} and uses them to replace some custom tasks.
More can be refactored later.
R=ahaas@chromium.org
Bug: v8:8238
Change-Id: I88bd2c9bd57ebc32d082528f2e4251d741a0d021
Reviewed-on: https://chromium-review.googlesource.com/c/1256773
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56367}
