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}
This is a hack to make sure the atomic operations don't
use the kRootRegister ebx before code generation.
I've filed v8:8254 to track that a larger clean-up operation
will be needed to remove this and other hacks.
Change-Id: I6f28f01ba2f96257a9e65eaa36fcad66b01906dd
Bug: v8:6666, v8:8254
Reviewed-on: https://chromium-review.googlesource.com/c/1256862
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56366}
This reverts commit ef2a19a211.
Reason for revert: Broken layout tests: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/201392
Original change's description:
> Add fast path for spreading primitive strings.
>
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
>
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
>
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}
TBR=ulan@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org,dhai@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:881273, v8:7980
Change-Id: I4868160b87bdebf9fd2ff346aefd4cdce23681a1
Reviewed-on: https://chromium-review.googlesource.com/c/1261022
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56365}
This undoes the workaround from https://crrev.com/c/1223426.
Bug: chromium:887888
Change-Id: Id7a68354b1f1020d7d001ba4120be8a11f896067
Reviewed-on: https://chromium-review.googlesource.com/c/1260942
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56364}
This introduces a new flag --async-stack-traces, which enables zero-cost
async stack traces. This enriches the non-standard Error.stack property
with async stack frames computed from walking up the promise chains and
collecting all the await suspension points along the way. In Error.stack
these async frames are marked with "async" to make it possible to
distinguish them from regular frames, for example:
```
Error: Some error message
at bar (<anonymous>)
at async foo (<anonymous>)
```
It's zero-cost because no additional information is collected during the
execution of the program, but only the information already present in the
promise chains is used to reconstruct an approximation of the async stack
in case of an exception. But this approximation is limited to suspension
points at await's in async functions. This depends on a recent ECMAScript
specification change, flagged behind --harmony-await-optimization and
implied the --async-stack-traces flag. Without this change there's no
way to get from the outer promise of an async function to the rest of
the promise chain, since the link is broken by the indirection introduced
by await.
For async functions the special outer promise, named .promise in the
Parser desugaring, is now forcible allocated to stack slot 0 during
scope resolution, to make it accessible to the stack frame construction
logic. Note that this first prototype doesn't yet work fully support
async generators and might have other limitations.
Bug: v8:7522
Ref: nodejs/node#11865
Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1256762
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56363}
When projection nodes are optimized, TempRegisters are used, which
don't check to see if the registers are already in use.
UseUniqueRegisters instead.
Change-Id: I6a327098067daa3328355380da666d404fcc8b46
Bug: v8:8202, v8:6532
Reviewed-on: https://chromium-review.googlesource.com/c/1259107
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56360}
fixed Abort() calling sequence on platforms with function descriptors by taking
function descriptor of the External Reference object into account when calling
C code.
Change-Id: I54c04a5f1774f2768380cc5c95b1b807204335ce
Reviewed-on: https://chromium-review.googlesource.com/c/1258186
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56356}
In C to WASM stubs, when number of parameters is more than 5, or
anything requires stack arguments, current linkage is faulty
because of missing STACK_SHADOW_WORDS
Drive-by: Also cleanup s390 code which is not supported anymore.
R=joransiu@ca.ibm.com
Change-Id: I7405c32fd94e158e6868f9ce7d4390c995078dbb
Reviewed-on: https://chromium-review.googlesource.com/c/1257269
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56352}
This is part of clean-up for a new Clang warning that we'd like to
enable. This patch addresses all warnings from V8 that I saw in a full debug
build of Chromium on Linux.
../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment
operator is implicitly deleted [-Wdefaulted-function-deleted]
RelocIterator& operator=(RelocIterator&&) = default;
^
../../v8/src/reloc-info.h:447:13: note: move assignment operator of
'RelocIterator' is implicitly deleted because field 'mode_mask_' is of
const-qualified type 'const int'
const int mode_mask_;
^
../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly
defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler);
^
../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor
of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted
move constructor
LiftoffAssembler asm_;
^
../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move
assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle);
^
../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of
'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a
deleted move assignment operator
WasmInterpreter interpreter_;
^
../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of
'WasmInterpreter' is implicitly deleted because field 'internals_' is of
const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const'
WasmInterpreterInternals* const internals_;
^
Bug: chromium:890307
Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc
Reviewed-on: https://chromium-review.googlesource.com/c/1256863
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56351}
By moving the block range end to left of closing bracket,
we can avoid ambiguity where an open-ended singleton range
could be both interpreted as inside the parent range, or
next to it.
R=verwaest@chromium.org
Bug: v8:8237
Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
Reviewed-on: https://chromium-review.googlesource.com/1254127
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56347}
The root register is not available in JS-to-Wasm functions, and
this was not reflected in the linkage. Similarily, it is not
available in C-to-Wasm functions.
Change-Id: I2dbfd06ef99d6f9b9940e9489f563441d9ebfabd
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/1256766
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56346}
