Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.
Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}
In the ElementsAccessor fast-path for Array.prototype.includes, we
iterate backing-store elements according to start and length numbers
which might or might not be within the JSArray::length field, for
example when side-effects changed the receiver while start and length
are computed. So even when we have a packed ElementsKind, we might still
observe the hole. This is fine, since logical out-of-bounds accesses
are safe in this case, but it means we must not rely on the
ElementsKind telling us if we can encounter holes.
Bug: chromium:897098
Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8
Reviewed-on: https://chromium-review.googlesource.com/c/1293571
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56884}
Change the status files to only run on release bots and furthermore
exclude those that run on an arm simultaor. This should still provide
sufficient coverage while keeping resource usage at bay.
Bug: v8:8331, v8:8332
Change-Id: I515e68929af660932a1224294bd09ebc05705324
Reviewed-on: https://chromium-review.googlesource.com/c/1292061
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56850}
This adds an attribute field to the binary encoding of exception types
in the exceptions and import section. Currently the attribute value is
not used and expected to be zero, but it ensures the binary encoding is
extensible for future changes.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8153
Change-Id: I6f0e10cb1b6515177d8200ebf1f4f0b122832868
Reviewed-on: https://chromium-review.googlesource.com/c/1291075
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56841}
With async_hooks it's also possible that the "current microtask" is an
await task, whose generator is already suspended, when there's an
exception thrown in the AFTER callback. In that case we cannot build
a meaningful async stack trace.
Bug: chromium:897406, v8:7522
Change-Id: I682dc1fc3ebb1864e1c2061041ff99ced0313f0c
Reviewed-on: https://chromium-review.googlesource.com/c/1292057
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56839}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
The original version of this patch had an overly agressive assert that has
been loosened.
TBR=jgruber@chromium.org
Change-Id: I56870862f4b124d1b38372daa326182a526c874c
Reviewed-on: https://chromium-review.googlesource.com/c/1291375
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56829}
The atomics and compare-exchange stress tests are intended to test
code generation only anyway and can be quite slow. So skip all the
variants.
Notry: true
Change-Id: Idf443b134558990c7eac43301fa816399794b9d5
Reviewed-on: https://chromium-review.googlesource.com/c/1291077
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56820}
The atomics stress tests use shared array buffers to record
non-deterministic interleaving of execution in web workers. This
produces non-deterministic heap results even in predictable mode.
NOTRY=true
Change-Id: Ic41c53bb6f5c67393fed7b9670c13cee6bc3481b
Reviewed-on: https://chromium-review.googlesource.com/c/1290979
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56819}
This reverts commit 41ba3d3eb0.
Reason for revert: Speculative revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Fuzzer/27370https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20predictable/19895
Original change's description:
> [builtins] Implement Array.prototype.slice in Torque
>
> In the process:
>
> - add volatile types for FastJSArray and remove the length_fast accessor
> from JSArray with the application of more rigorous typing.
> - add micro benchmarks for testing all the interesting slice cases
>
> Also update a few assorted places in .tq code to make them more
> idiomatic.
>
> Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
> Reviewed-on: https://chromium-review.googlesource.com/c/1281603
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56806}
TBR=danno@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I1f2c82b4c3ab0848857f620facacf9604d4fcd11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1290973
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56815}
This test is modelled after the atomics-stress test but supports 64 bit
operands.
Bug: v8:6532
Change-Id: I313b1ade74a58201b3fa097ba5b1515754a685db
Reviewed-on: https://chromium-review.googlesource.com/c/1234414
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56812}
This test runs random sequences of atomic wasm operations on multiple
threads and tries to compute an equivalent sequential interleaving that
would reproduce intermediate results.
By its nature, this test might time out and is flaky.
Bug: v8:6532
Change-Id: Iafdab4561cbf37a5c3fa9b8af9d0fbaaf5681608
Reviewed-on: https://chromium-review.googlesource.com/c/1195366
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56810}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
Reviewed-on: https://chromium-review.googlesource.com/c/1281603
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56806}
When --async-stack-traces is on and there's an exception from within an
async_hook "after" handler, we will be faced with a settled promise. In
that case we cannot do anything, since the promise will not have any
reactions on it anymore, but we should also not crash of course.
Bug: chromium:896700, v8:7522
Change-Id: I6e3d212d0433da40740489ff7421c5a98cf9bff3
Reviewed-on: https://chromium-review.googlesource.com/c/1290550
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56801}
This is a reland of a12203c64b
Original change's description:
> [wasm] Add a new wasm-js testsuite to run js-api tests
>
> These changes were necessary to run with the new style of jsapi tests
> introduced in https://github.com/WebAssembly/spec/pull/883.
>
> Change-Id: I4629dd48d595ed97ed0607dec9e7d9808c706a7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1277724
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56745}
Change-Id: I25fcd95bfc1aee1d21da390359423e5dfed112a4
Reviewed-on: https://chromium-review.googlesource.com/c/1286952
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56791}
When InferReceiverMaps doesn't provide us with reliable maps for the
resolution, we can still utilize the information if all the maps that
are found are stable - aka leaf - maps. But in that case we need to
make sure that we add proper dependencies on the stability of these
maps.
Bug: v8:7253
Change-Id: I6f5825583acc3f2575e83a244d55609ac64d04d3
Reviewed-on: https://chromium-review.googlesource.com/c/1288633
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56789}
If the user's cleanup function didn't iterate all available WeakCells, we need
to schedule the cleanup task again at some point. The previous condition
resulted it never being scheduled.
BUG=v8:8179
Change-Id: I8f5f4c01d1eb6a3cca8bd21bdc52c38663889882
Reviewed-on: https://chromium-review.googlesource.com/c/1286686
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56772}
When creating the buffer for the fall back, the initial entry was not
considered when calculating the size.
Bug: chromium:896181
Change-Id: I7f15bb1bdf31b3255db91b1fe8dcd68c76033980
Reviewed-on: https://chromium-review.googlesource.com/c/1286957
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56768}
This is necessary for the arguments adaptor, as there are only
5 gp registers available and a call to the arguments adaptor
trampoline that does not have the trampoline address as a immediate
needs 6 (4 arguments + esi as context + register to call through).
Bug: v8:6666
Change-Id: Ie96cf0352c323e07e0daf369953df8f4ee9acb81
Reviewed-on: https://chromium-review.googlesource.com/c/1283050
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56767}
AllocateJSArray always allocates in new space, so we bailout of the fast
path for strings if the new array does not fit in new space.
Bug found by ClusterFuzz. Regression test added.
This also switches to the BranchIf pattern to avoid materialize a bool.
Bug: chromium:895860, v8:7980
Change-Id: Ic7c41268c394ac2796b7694252390ab50fd74838
Reviewed-on: https://chromium-review.googlesource.com/c/1286337
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56759}
This reverts commit a12203c64b.
Reason for revert: Breaks isolate_tests
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20builder/36777
Original change's description:
> [wasm] Add a new wasm-js testsuite to run js-api tests
>
> These changes were necessary to run with the new style of jsapi tests
> introduced in https://github.com/WebAssembly/spec/pull/883.
>
> Change-Id: I4629dd48d595ed97ed0607dec9e7d9808c706a7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1277724
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56745}
TBR=binji@chromium.org,machenbach@chromium.org,yangguo@chromium.org,ahaas@chromium.org,clemensh@chromium.org,mathias@chromium.org
Change-Id: I2edd0ca94cb5990322571879c81671fa835f3ecd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1286526
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56746}
These changes were necessary to run with the new style of jsapi tests
introduced in https://github.com/WebAssembly/spec/pull/883.
Change-Id: I4629dd48d595ed97ed0607dec9e7d9808c706a7e
Reviewed-on: https://chromium-review.googlesource.com/c/1277724
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56745}
This CL extends IterableToListWithSymbolLookup with fast paths
for spreading keys/values iterators of JSMap, and values iterator
of JSSet (which is also the iterator of Set.prototype.keys() and
Set.prototype[Symbol.iterator]()). The fast paths are only taken
if the target still has original iteration behavior.
For iterators it is also required that the iterator is not
partially consumed. After spreading, to be spec-compliant, the
iterator is exhausted. Tests are added.
Bug: v8:7980
Change-Id: Ida74e5ecbbc5ba5488d13a40f2c4bda14c781cbf
Reviewed-on: https://chromium-review.googlesource.com/c/1276632
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56716}
This skips the slowest tests in stress and noopt variants.
TBR=sigurds@chromium.org
NOTRY=true
Bug: v8:7783
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic471a2ab3e6806c4c60b81c0cdddfb44b199dd26
Reviewed-on: https://chromium-review.googlesource.com/c/1286334
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56715}
This also includes ports of Array.p.toString and Array.p.toLocaleString.
Many parts of the old JS implementation are preserved, because
TypedArray.p.join still relies on it. These will be removed once
TypedArray.p.join is ported to Torque.
To simplify implementation, special handling of extremely sparse arrays
has been removed.
Performance improvements vary by array size, elements, and sparse-ness.
Some quick numbers and graphs are here:
https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia4069a068403ce36676c37401d349aefc976b045
Reviewed-on: https://chromium-review.googlesource.com/c/1196693
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56699}
Previously when class names were computed and set as part of
StoreDataPropertyInLiteral calls, it was observable to static fields
as these static fields are initialized right after the classes were
constructed but before the class names were installed.
This caused the name property to be undefined for this case.
Instead, this patch always forces the creation of a name property on
the class constructor when static class fields are used. This patch
does kill the class boilerplate optimization, but currently all static
class fields are installed using a runtime call to CreateDataProperty
so this isn't any worse when using static class fields.
In the future, this can be optimized away by storing the name on the
boilerplate.
There is spec discussion here:
https://github.com/tc39/proposal-class-fields/issues/85
There isn't a resolution yet, there's still discussion about whether
to have the name be undefined always for static class field
initializers. But, I don't think that's useful as it would always kill
our boilerplate optimization (like this patch does ..., but without the
future optimization potential).
Bug: v8:5367
Change-Id: I14afdf7ece3f2d9fa3c659d2c0bc3806e0b17abb
Reviewed-on: https://chromium-review.googlesource.com/c/1281002
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56686}
This switches the encoding of the exceptions (in the exceptions as well
as the import section) to use a signature index instead of a flat type
vector encoding. Note that only signatures that have a void return type
can be used for declaring exceptions.
R=clemensh@chromium.org
BUG=v8:8153
Change-Id: I481ccbce9ddf29becdf4ed7ceffe80d6145446e1
Reviewed-on: https://chromium-review.googlesource.com/c/1280323
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56654}
The race happens when the sweeper is looking up the size of an object
that had its map replaced concurrently.
The fix is to load the object map using an acquire load so that the
sweeper observes the initializing stores of the new map.
Bug: v8:8303
Change-Id: Ifaaef06cb815be7d07b6a574085ee61a466bc1d6
Reviewed-on: https://chromium-review.googlesource.com/c/1280310
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56652}
Change-Id: I982f3615136c7a4ba18e4a6d2cc06a3e24e22f54
Reviewed-on: https://chromium-review.googlesource.com/c/1277722
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56645}
For serialization we are using the code table to find the code of all
functions. We want to serialize compiled code though, not interpreter
entries (we currently fail a DCHECK there).
This CL changes the logic to not update the code table with interpreter
entries but instead keeps a separate bit set of interpreted functions.
R=mstarzinger@chromium.org
Bug: v8:8177, chromium:735509
Change-Id: I69c59f92712135ddef667b54114614fad94cc6fc
Reviewed-on: https://chromium-review.googlesource.com/c/1278794
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56644}
Split the runtime function for initializing a promise into AwaitPromisesInit
and AwaitPromisesInitOld, the former not firing the INIT hook and being used
by the AwaitOptimized builtin. In addition to this the AsyncHooks now caches
all the previously inited promises and checks that the init hook is not fired
twice for the same promise.
Modified test expectations for the new async ids in the async hooks tests.
Bug: v8:8300
Change-Id: If4a17e501b2a233578fa70b6442f219473f001d9
Reviewed-on: https://chromium-review.googlesource.com/c/1280442
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56642}
Properly handle the case where the CheckFloat64Hole becomes a
no-op after RETYPE (because the feedback type is already Number).
We always need to pass the Number restriction type here.
Bug: chromium:895199
Change-Id: I96a949ba35db1e6d35abedddc4507c101d95b716
Reviewed-on: https://chromium-review.googlesource.com/c/1278804
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56622}
This fixes the typing for the case when the call is not lowered to
the simplified operator.
Bug: chromium:880207
Change-Id: Icecf12de77ece0fe9ffec2777874f5f0004a1e97
Reviewed-on: https://chromium-review.googlesource.com/c/1278642
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56621}
For the --async-stack-traces we can also look through initial parts of
the promise chain that were created by regular Promise#then() calls to
walk up to the first async function frame. This addresses the missing
support for aforementioned example
```js
(async function() {
await Promise.resolve().then(() =>
console.log(new Error().stack));
})();
```
which now also works.
Bug: v8:7522
Change-Id: I574943c1fc6ee4a1bd56f208dce78eb7506c5c4f
Reviewed-on: https://chromium-review.googlesource.com/c/1278276
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56613}
Updated the test so that it uses assertPromiseResult, which makes sure that
a promise rejection is not swallowed. The change is reflected in the actual
async ids, checked in the test.
Bug: v8:8300
Change-Id: Ie227ca74a8cf4e0e079809b21c3abc5a5f87c11a
Reviewed-on: https://chromium-review.googlesource.com/c/1278388
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56608}
Adds support for enqueuing parallel parse / compile tasks for eagerly
compiled IIFEs during parsing. If the --parallel-compile-tasks flag is
enabled, the parser will pre-parse eager top-level IIFEs and enqueue a
task on the compiler dispatcher to do the actual parsing / compilation
on a worker thread.
Currently we always enqueue the task, but we likely want to only
enqueue parallel tasks where the script has multiple IIFEs or a
substantial amount of top-level script code before the IIFE to avoid
the main thread having to immediately block on the parallel task. This
work will be done as a follow-up.
BUG=v8:8041
Change-Id: If68d7c374548cabd4ec32f1fb6752da7d6aaae6b
Reviewed-on: https://chromium-review.googlesource.com/c/1275354
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56593}
On ia32, we were pinning too many registers, resulting in no unpinned
byte registers left (we only have three byte registers since {ebx}
is reserved for the root register).
It turns out that on most paths, we don't actually need to pin any
registers, since {Store} is often the last call for an operation (like
any store or set_global). If registers need to be pinned, only pass
those that must be kept alive across the {Store}. This allows to
compute a more narrow set of pinned registers on demand inside {Store}.
Plus minor drive-by changes.
R=titzer@chromium.org
Bug: chromium:894374, chromium:894307, v8:6600
Change-Id: Ic4d7131784c193dc7a2abf0e504d9973f6d5c5f1
Reviewed-on: https://chromium-review.googlesource.com/c/1275819
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56587}
This makes sure that catch blocks that are practically unreachable due
to missing exceptional projections are handled properly. Note that this
is independent of how reachability will be outlined in the final spec
for exception handling. Currently we just assume that all catch blocks
are spec-wise reachable.
R=titzer@chromium.org
TEST=mjsunit/wasm/exceptions-catchall
BUG=v8:8091
Change-Id: I13607a59bd76be146df836e88105a2fbafedb760
Reviewed-on: https://chromium-review.googlesource.com/c/1273018
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56556}
This is behind a new flag --harmony-namespace-exports.
Bug: v8:8101
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9c252b6de2b08223fcf3296340b78d721471bdb4
Reviewed-on: https://chromium-review.googlesource.com/c/1258004
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56550}
Use naming similar to the spec: "table" instead of "function table",
"element segment" instead of "function table init".
Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff
Reviewed-on: https://chromium-review.googlesource.com/c/1273612
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56545}
The NumberMultiply typing rule gave up in the presence of NaN inputs,
but we can still infer useful ranges here and just union the result
of that with the NaN propagation (similar for MinusZero propagation).
This way we can still makes sense of these ranges at the uses.
Bug: v8:8015
Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
Reviewed-on: https://chromium-review.googlesource.com/c/1261143
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56539}
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
The MapIterator protector protects the original iteration behaviors of
Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries().
It does not protect the original iteration behavior of
Map.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
%MapIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
holder is the %IteratorPrototype%. Note that this also invalidates the
SetIterator protector (see below).
The SetIterator protector protects the original iteration behavior of
Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(),
and Set.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
%SetIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
holder is the %SetPrototype% OR %IteratorPrototype%. This means that
setting Symbol.iterator on a MapIterator object can also invalidate the
SetIterator protector, and vice versa, setting Symbol.iterator on a
SetIterator object can also invalidate the MapIterator. This is an over-
approximation for the sake of simplicity.
Bug: v8:7980
Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871
Reviewed-on: https://chromium-review.googlesource.com/c/1273102
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56530}
This CL refactors the implementation of WASM->JS import wrappers in order
to make the wrapper code shareable. Instead of specializing to the import
index, we use a tuple as the object ref in the both the import and indirect
tables. The tuple allows the wrapper code to load both the calling
instance and the target callable, rather than relying on code specialization.
This requires some tricky codegen machinery, because WASM call descriptors
expect an instance argument in a given register, yet the wrappers receive
a tuple, the code generator must generate a prologue that loads the
instance (and the callable), since it is not possible to express this at
the graph level.
R=mstarzinger@chromium.orgCC=clemensh@chromium.org
Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
Reviewed-on: https://chromium-review.googlesource.com/c/1268237
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56520}
This reverts commit 471fef0469.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> 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}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.
We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.
In essence we now turn an async function like
```js
async function f(x) { return await bar(x); }
```
into something like this (in Parser and BytecodeGenerator respectively):
```
function f(x) {
.generator_object = %_AsyncFunctionEnter(.closure, this);
.promise = %AsyncFunctionCreatePromise();
try {
.tmp = await bar(x);
return %_AsyncFunctionResolve(.promise, .tmp);
} catch (e) {
return %_AsyncFunctionReject(.promise, e);
}
}
```
Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function
```js
async function f(x) { return await x; }
```
goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.
Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!
Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
The test started flaking on almost every run since 1 day, disabling
until the root cause is triaged.
NOTRY=true
Bug: v8:8219
Change-Id: Id3cf219874e79cefc41bb63a9a4a04b6288d5350
Reviewed-on: https://chromium-review.googlesource.com/c/1270942
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56488}
This fixes handling of two corner cases with catch-all blocks:
1) The catch-all blocks are conceptually outside the corresponding try.
2) Reachability of catch-all is determined by parent reachability.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-catchall
BUG=v8:8091
Change-Id: Idfd8310bc232f3ce389763023c5a33f1ef90e0b5
Reviewed-on: https://chromium-review.googlesource.com/c/1270816
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56486}
This adds support for multiple catch blocks being attached to a single
try block. The implemented semantics are that type checks are performed
in order from top to bottom.
Note that multiple catch blocks of the same type are not prohibited and
will be accepted, making the second such block essentially unreachable.
The current proposal neither explicitly allows nor prohibits it.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I31e7a07a7cffdd909a58342e00f05e52ed1a3182
Reviewed-on: https://chromium-review.googlesource.com/c/1270591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56478}
This adds support to wire control flow of catch-all expressions into an
existing try-catch cascade. Note that multiple typed catch blocks are
not yet supported, only one typed catch block followed by one catch-all
block is supported.
In case the explicit catch-all block is missing, we emulate the correct
semantics by internally always emitting a catch-all containing a simple
rethrow instruction.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-catchall
BUG=v8:8091
Change-Id: I6b29a98c4f1a558fabe6012f4ba6c7b7d43529bb
Reviewed-on: https://chromium-review.googlesource.com/c/1270585
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56476}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
This adds support to the escape analysis to allow scalar replacement
of (small) FixedArrays with element accesses where the index is not a
compile time constant. This happens quite often when inlining functions
that operate on variable number of arguments. For example consider this
little piece of code:
```js
function sum(...args) {
let s = 0;
for (let i = 0; i < args.length; ++i) s += args[i];
return s;
}
function sum2(x, y) {
return sum(x, y);
}
```
This example is made up, of course, but it shows the problem. Let's
assume that TurboFan inlines the function `sum` into it's call site
at `sum2`. Now it has to materialize the `args` array with the two
values `x` and `y`, and iterate through these `args` to sum them up.
The escape analysis pass figures out that `args` doesn't escape (aka
doesn't outlive) the optimized code for `sum2` now, but TurboFan still
needs to materialize the elements backing store for `args` since there's
a `LoadElement(args.elements,i)` in the graph now, and `i` is not a
compile time constant.
However the escape analysis has more information than just that. In
particular the escape analysis knows exactly how many elements a non
escaping object has, based on the fact that the allocation must be
local to the function and that we only track objects with known size.
So in the case above when we get to `args[i]` in the escape analysis
the relevant part of the graph looks something like this:
```
elements = LoadField[elements](args)
length = LoadField[length](args)
index = CheckBounds(i, length)
value = LoadElement(elements, index)
```
In particular the contract here is that `LoadElement(elements,index)`
is guaranteed to have an `index` that is within the valid bounds for
the `elements` (there must be a preceeding `CheckBounds` or some other
guard in optimized code before it). And since `elements` is allocated
inside of the optimized code object, the escape analysis also knows
that `elements` has exactly two elements inside (namely the values of
`x` and `y`). So we can use that information and replace the access
with a `Select(index===0,x,y)` operation instead, which allows us to
scalar replace the `elements`, since there's no escaping use anymore
in the graph.
We do this for the case that the number of elements is 2, as described
above, but also for the case where elements length is one. In case
of 0, we know that the `LoadElement` must be in dead code, but we can't
just mark it for deletion from the graph (to make sure it doesn't block
scalar replacement of non-dead code), so we don't handle this for now.
And for one element it's even easier, since the `LoadElement` has to
yield exactly said element.
We could generalize this to handle arbitrary lengths, but since there's
a cost to arbitrary decision trees here, it's unclear when this is still
beneficial. Another possible solution for length > 2 would be to have
special stack allocation for these backing stores and do variable index
accesses to these stack areas. But that's way beyond the scope of this
isolated change.
This change shows a ~2% improvement on the EarleyBoyer benchmark in
JetStream, since it benefits a lot from not having to materialize these
small arguments backing stores.
Drive-by-fix: Fix JSCreateLowering to properly initialize "elements"
with StoreElement instead of StoreField (which violates the invariant
in TurboFan that fields and elements never alias).
Bug: v8:5267, v8:6200
Change-Id: Idd464a15a81e7c9653c48c814b406eb859841428
Reviewed-on: https://chromium-review.googlesource.com/c/1267935
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56442}
This change adds predicates to check whether a given JavaScript operator
needs the "current context" or if any surrounding context (including the
"native context") does it. For example JSAdd doesn't ever need the
current context, but actually only the native context. In the
BytecodeGraphBuilder we use this predicate to check whether a given
operator needs the current context, and if not, we just pass in the
native context.
Doing so we improve the performance on the benchmarks given in the
tracking bug significantly, and go from something around
arrayMap: 476 ms.
arrayFilter: 312 ms.
arrayEvery: 241 ms.
arraySome: 152 ms.
to
arrayMap: 377 ms.
arrayFilter: 296 ms.
arrayEvery: 191 ms.
arraySome: 91 ms.
which is an up to 40% improvement. So for idiomatic modern JavaScript
which uses higher order functions quite a lot, not just the builtins
provided by the JSVM, this is going to improve peak performance
noticably.
This also makes it possible to completely eliminate all the allocations
in the aliased sloppy arguments example
```js
function foo(a) { return arguments.length; }
```
concretely we don't allocate the function context anymore and we also
don't allocate the arguments object anymore (the JSStackCheck was the
reason why we did this in the past, because it was holding on to the
current context, which also kept the allocation for the arguments
alive).
Bug: v8:6200, v8:8060
Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef
Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators
Reviewed-on: https://chromium-review.googlesource.com/c/1267176
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56441}
This is a reland of ef2a19a211.
Use AllocateJSArray to avoid allocating an empty fixed array.
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}
Bug: chromium:881273, v8:7980
Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3
Reviewed-on: https://chromium-review.googlesource.com/c/1267497
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56438}
As identified in the web-tooling-benchmark, there are specific code
patterns involving array indexed property accesses and subsequent
comparisons of those indices that lead to repeated Smi checks in the
optimized code, which in turn leads to high register pressure and
generally bad register allocation. An example of this pattern is
code like this:
```js
function f(a, n) {
const i = a[n];
if (n >= 1) return i;
}
```
The `a[n]` property access introduces a CheckBounds on `n`, which
later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
however the `n >= 1` comparison has collected `SignedSmall` feedback
and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
second Smi check is redundant and cannot easily be combined with the
earlier tagged->int32 conversion, since that also deals with heap
numbers and even truncates -0 to 0.
So we teach the RedundancyElimination to look at the inputs of these
speculative number comparisons and if there's a leading bounds check
on either of these inputs, we change the input to the result of the
bounds check. This avoids the redundant Smi checks later and generally
allows the SimplifiedLowering to do a significantly better job on the
number comparisons. We only do this in case of SignedSmall feedback
and only for inputs that are not already known to be in UnsignedSmall
range, to avoid doing too many (unnecessary) expensive lookups during
RedundancyElimination.
All of this is safe despite the fact that CheckBounds truncates -0
to 0, since the regular number comparisons in JavaScript identify
0 and -0 (unlike Object.is()). This also adds appropriate tests,
especially for the interesting cases where -0 is used only after
the code was optimized.
Bug: v8:6936, v8:7094
Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
Reviewed-on: https://chromium-review.googlesource.com/c/1246181
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56428}
This reverts commit 4fd92b252b.
Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots)
Original change's description:
> [turbofan] Do not consume SignedSmall feedback in TurboFan anymore.
>
> 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}
TBR=jarin@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7094
Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404
Reviewed-on: https://chromium-review.googlesource.com/c/1267175
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56427}
The RNG state is initialized with random_seed parameter that usually
has lots of zeros. Each random generation iteration shuffles bits with
xor operation over the state. It takes a while before the state is populated
with enough 1s and starts generating uniformly distributed numbers.
The patch warms up the state with 32 iterations when --random_seed is used.
BUG=v8:8265
Change-Id: I7a4e8c842962bea0f2935c7b3673494367d8580f
Reviewed-on: https://chromium-review.googlesource.com/c/1263816
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56418}
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}
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}
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}
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}
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}
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}
Following up on the earlier work regarding redundant Smi checks in
https://chromium-review.googlesource.com/c/v8/v8/+/1246181, it was
noticed that the handling of the 0 and -0 and how some operations
identify these is not really consistent, but was still rather ad-hoc.
This change tries to unify the handling a bit by making sure that all
number comparisons generally pass truncations that identify zeros, since
for the number comparisons in JavaScript there's no difference between
0 and -0. In the same spirit NumberAbs and NumberToBoolean should also
pass these truncations, since they also don't care about the differences
between 0 and -0.
Adjust NumberCeil, NumberFloor, NumberTrunc, NumberMin and NumberMax
to pass along any incoming kIdentifiesZeros truncation, since these
operations also don't really care whether the inputs can be -0 if the
use nodes don't care.
Also utilize the kIdentifiesZeros truncation for NumberModulus with
Signed32 inputs, because it's kind of common to do something like
`x % 2 === 0`, where it doesn't really matter whether `x % 2` would
eventually produce a negative zero (since that would still be considered
true for the sake of the comparison).
This also adds a whole lot of tests to ensure that not only are these
optimizations correct, but also that we do indeed perform them.
Drive-by-fix: The `NumberAbs(x)` would incorrectly lower to just `x` for
PositiveIntegerOrMinusZeroOrNaN inputs, which was obviously wrong in
case of -0. This was fixed as well, and an appropriate test was added.
The reason for the unification is that with the introduction of Word64
for CheckBounds (which is necessary to support large TypedArrays and
DataViews) we can no longer safely pass Word32 truncations for the
interesting cases, since the index might be outside the Signed32 or
Unsigned32 ranges, but we still identify 0 and -0 for the sake of the
bounds check, and so it's important that this is handled consistently
to not regress performance on TypedArrays and DataViews accesses.
Bug: v8:8015, v8:8178
Change-Id: Ia1d32f1b726754cea1e5793105d9423d84a6393a
Reviewed-on: https://chromium-review.googlesource.com/1246172
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56325}
The protector is useful for follow-up optimizations on string iterator.
Tests are also added.
Change-Id: I416037c742628c4d4d3b878d0df727a9ae7162f7
Reviewed-on: https://chromium-review.googlesource.com/1251122
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56315}
Delay the creation of FunctionNameVariables until we validated the
FormalParameters. This is needed so we don't declare them in cases where
we later get an error, have to reset, and reparse.
Bug: chromium:890553, v8:7926
Change-Id: I742e6f7f71158e3903843bd583dc7943468c18f6
Reviewed-on: https://chromium-review.googlesource.com/1254061
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#56314}
It was shipped in Chrome 67.
Bug: v8:6791, v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I94d8f0aa18570452403a35dea270b18f155c970a
Reviewed-on: https://chromium-review.googlesource.com/1253604
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56310}
Currently, we call the MapRef::AsElementsKind method on an initial
map multiple times (from JSCreateLowering::ReduceJSCreateArray).
However, this does not does not play well with the heap copier/broker,
which only expectes AsElementsKind to be called on initial maps.
This CL makes sure we only call AsElementsKind once (on the initial map).
Bug: chromium:890620
Change-Id: If44421d3900abb7629ea8f789a005b8d8ebaf881
Reviewed-on: https://chromium-review.googlesource.com/1253105
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56307}
The representation changer was lacking support for directly converting
Word64 values to Bit representation.
Bug: chromium:890243, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: I5fa31716c7b2b10ad00dc31d5035a1ada152661c
Reviewed-on: https://chromium-review.googlesource.com/1251551
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56304}
Bug: chromium:890057
Change-Id: I98bc278ebc202c3d8f6417367bd1c592e4824011
Reviewed-on: https://chromium-review.googlesource.com/1250481
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56279}
This adds a stress test for the I64 variants of the
AtomicCompareExchange opcodes.
Bug: v8:6532
Change-Id: Iaba4f31f944a71393e5c3222d364d214ff482b9e
Reviewed-on: https://chromium-review.googlesource.com/1235913
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56261}
- Add a new broker mode kRetired, in which the heap can
again be accessed.
- Change the way modes work. We now always start in kDisabled.
If FLAG_concurrent_compiler_frontend is on, we eventually move
to kSerializing, then to kSerialized, then to kRetired.
- Add an ObjectDataKind to ObjectData that indicates whether the
data is just a dummy (i.e. created while broker was in kDisabled
mode).
This also happens to fix a bug found by clusterfuzz.
Bug: v8:7790, chromium:889722
Change-Id: I38833fe7ad26d2d3efb15ba560576defb82f673a
Reviewed-on: https://chromium-review.googlesource.com/1245425
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56260}
I moved AnalyzePartially from ParseFunctionLiteral to SkipFunction, but arrow
functions only used the ResetAfterPreparsing part.
Bug: chromium:888825
Change-Id: I08de99af128b28031df6ed86a725e4dc918078f8
Reviewed-on: https://chromium-review.googlesource.com/1243383
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56218}
When constructing a TypedArray by length, only actually setup the
JSTypedArray instance once the buffer is allocated, as only at that
time it's known whether the byte length is fine. Otherwise we confuse
the heap verifier.
Bug: chromium:887891
Change-Id: I407ff9a2a053dd11ef764e4e32f482abb27eb0a8
Reviewed-on: https://chromium-review.googlesource.com/1238494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56131}
Remove %ToPrimitive, %ToPrimitive_Number, %SameValue and %SameValueZero,
as these runtime functions were only used from tests. For the %SameValue
we use Object.is() to test the internal algorithm (the actual one even),
and for %SameValueZero we use Set#has() - this was already the case for
most uses anyways.
Also drop %IsDate and %ValueOf, which didn't have uses at all.
Bug: v8:8015
Change-Id: Ice26d25e68aed4d5d8adac0547c56aedf9826b13
Reviewed-on: https://chromium-review.googlesource.com/1237677
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56127}
The order in which ToNumber(left) and ToPrimitive(right,hint Number)
is called when performing an abstract relational comparison is
observable, and we need to make sure to trigger the conversions in
the correct order.
Bug: chromium:687063
Change-Id: Idc9edb99643c4cf1774b89dcdc319ed5dc7cdc8a
Reviewed-on: https://chromium-review.googlesource.com/1236557
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56125}
Properly test the abstract equality - both JSEqual and JSNotEqual - for
the case of symbols. Also add tests for the corner cases of the
JSObjectIsArray operator, which is used to implement Array.isArray()
builtin.
Bug: v8:8015
Change-Id: Ib008e85553d04527a5992a904ec77774761f872e
Reviewed-on: https://chromium-review.googlesource.com/1238237
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56121}
Improve the lowering of CheckedInt32Div and CheckedUint32Div for the
case that the right hand side is a known (positive) power of two, as
in that case it's sufficient to just check the relevant bits on the
left hand side and then shift by the appropriate amount of bits.
This is significantly faster than what TurboFan is able to generate
from the general lowering, even with all the MachineOperatorReducer
magic (it even shows as a steady ~1.5% overall improvement on the
Kraken crypto ccm benchmark).
Also turn the general CheckedInt32Div lowering into readable code again,
and make sure that all the bailout cases are properly covered by mjsunit
tests (i.e. the "division by zero" bailout was not covered properly).
Bug: v8:8015
Change-Id: Ibfdd367a6ee5d70dcaa48801858042c5029b7004
Reviewed-on: https://chromium-review.googlesource.com/1236954
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56115}
The previous tests didn't cover the case Number.isSafeInteger(x)
where TurboFan was unable to tell that `x` is always a Number and
thus had to use the ObjectIsSafeInteger operator instead.
Bug: v8:8015
Change-Id: I9bdbfa602fe0bf8c5fb2bc6c160ace7ab0bc0aaa
Reviewed-on: https://chromium-review.googlesource.com/1238234
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56114}
Again in the spirit of https://chromium-review.googlesource.com/1226033
we can simplify the handling of NumberDivide and decide the lowering
based on the feedback type.
Drive-by-fix: Add test coverage for the relevant corner cases of the
NumberDivide handling in SimplifiedLowering.
Bug: v8:8015
Change-Id: I0edaca0fddb31d64d2c269268e87a32a687a0b26
Reviewed-on: https://chromium-review.googlesource.com/1236262
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56113}
The ObjectIsArrayBuffer simplified operator, which is used to implement
the ArrayBuffer.isView() builtin, didn't have any test coverage.
Bug: v8:8015
Change-Id: Ia15e35bc4ae61627137f7a89976560a8d3db771f
Reviewed-on: https://chromium-review.googlesource.com/1238215
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56112}
Without this the call to `formatFailureText` in `test-async.js`
fails but goes unnoticed since the promise change is rejects
which is not handled. And d8 silently ignores the the unhandled
rejections.
Once `formatFailureText` was added it reveals a but where several
tests were expecting `.equal` to be a deepEquals. Specifically:
test/mjsunit/es6/promise-all.js
test/mjsunit/harmony/async-generators-resume-return.js
test/mjsunit/harmony/async-generators-return.js
test/mjsunit/harmony/async-generators-yield.js
Making equals call `deepEquals` fixed that issue.
Change-Id: I350c7d916147eaa7cf873bdaf273aebbaaa833c5
Reviewed-on: https://chromium-review.googlesource.com/1236852
Commit-Queue: Sam Clegg <sbc@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56107}
Previously, Atomics.notify was just an alias to Atomics.wake, which
doesn't quite let us add a use counter for these individual builtins.
This patch refactors the existing Atomics.wake into a separate
function that is called from two separate builtins.
Bug: v8:7883
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If54c8f769b7949d88d327cfb2f70db394f32a0b7
Reviewed-on: https://chromium-review.googlesource.com/1234581
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56105}
In the spirit of https://chromium-review.googlesource.com/1226033 we can
also unify the handling of NumberModulus based on feedback types.
Drive-by-fix: Add appropriate tests for the corner cases of the
NumberModules with (surrounding) feedback integration.
Bug: v8:8015
Change-Id: I5e3207d2f6e72f9ea1d7658014b7272075088d63
Reviewed-on: https://chromium-review.googlesource.com/1236260
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56094}
The coverage bot figured out that there's missing test coverage
for the SpeculativeNumberModulus corner cases inside of the
SimplifiedLowering logic.
Bug: v8:8015
Change-Id: Id32aa545dc43adae5e67c66574ccea5f2b3db846
Reviewed-on: https://chromium-review.googlesource.com/1236259
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56093}
This adds missing test coverage for corner cases of SpeculativeNumberAdd
and SpeculativeNumberSubtract inside of SimplifiedLowering. This was
discovered to be untested by the coverage bot.
Bug: v8:8015
Change-Id: I7355b1b840a76bc12bd911adb6c2d88f05d816c5
Reviewed-on: https://chromium-review.googlesource.com/1236256
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56090}
Part of https://chromium-review.googlesource.com/1231994 that landed
earlier, but was reverted due to breakage. Landing this cleanup
separately instead.
Drive-by-fix: Also add test coverage for the cases that weren't covered
properly (according to the test coverage bot).
Bug: chromium:225811, v8:8015
Change-Id: I9c13ed5fcf0ba9e6b190489e15df86970eafdc13
Reviewed-on: https://chromium-review.googlesource.com/1236213
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56087}
According to the coverage bot, there's some lack of test coverage for
corner cases of Math.imul(). Add the missing test coverage and also
add some coverage for the generally interesting cases.
Bug: v8:8015
Change-Id: I2a917283b4777510fb5db421a039ff0de9b2a25f
Reviewed-on: https://chromium-review.googlesource.com/1235577
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56077}
The following runtime functions (and their intrinsic counter parts) are
completely unused/obsolete by now
- %ToInteger
- %GeneratorGetInputOrDebugPos
and in addition the intrinsics for %_ToNumber and %_IsJSProxy are also
dead (according to code coverage and manual verification), so drop them
as well (their runtime function counterparts are still somewhat used).
Bug: v8:8015
Change-Id: I60d53762dd9717fb43de38cb490b46676c467212
Reviewed-on: https://chromium-review.googlesource.com/1235923
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56076}
Remove the NumberConstant right hand side limitation for the speculative
number operation optimization, and extend the logic to also deal with
SpeculativeToNumber, which is common when dealing with postfix increment
and array operations.
Also add appropriate tests for all the relevant cases, specifically we
mjsunit tests to increase the general coverage for the various cases
here (in addition to dedicated unittests).
Bug: v8:8015
Change-Id: I8c92f98490c63b07eb19686efd404322979e57c4
Reviewed-on: https://chromium-review.googlesource.com/1235919
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56072}
Previously we only supported strings and not filenames. This
changes the default to filename and adds a new `type: string` which can
be passed `options` to allow for strings to be passed in test code.
See: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker
Bug: v8:8020
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie8818885c5c5c071b6614852322cb45aeb01a647
Reviewed-on: https://chromium-review.googlesource.com/1185980
Commit-Queue: Sam Clegg <sbc@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56056}
This is a reland of 3bb5cb63da
Original change's description:
> [wasm] Introduce a soft limit on reserved memory
>
> Currently, wasm memory and wasm code use a shared limit for the total
> size of reservations. This can cause wasm code reservations to fail
> because wasm memories used all available reservation space.
> This CL introduces a soft limit which is used when allocating wasm
> memory with full guards. If this limit is reached and the respective
> flag is set, we fall back to allocation without full guards and check
> against the hard limit. Code reservations always check against the hard
> limit.
>
> R=ahaas@chromium.org
>
> Bug: v8:8196
> Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
> Reviewed-on: https://chromium-review.googlesource.com/1233614
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56028}
Bug: v8:8196
Change-Id: If8baf429b02e23b344346f7335bc911b99ae5579
Reviewed-on: https://chromium-review.googlesource.com/1233756
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56044}
This reverts commit 3bb5cb63da.
Reason for revert: Breaks Win64 bot https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/26418
Original change's description:
> [wasm] Introduce a soft limit on reserved memory
>
> Currently, wasm memory and wasm code use a shared limit for the total
> size of reservations. This can cause wasm code reservations to fail
> because wasm memories used all available reservation space.
> This CL introduces a soft limit which is used when allocating wasm
> memory with full guards. If this limit is reached and the respective
> flag is set, we fall back to allocation without full guards and check
> against the hard limit. Code reservations always check against the hard
> limit.
>
> R=ahaas@chromium.org
>
> Bug: v8:8196
> Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
> Reviewed-on: https://chromium-review.googlesource.com/1233614
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56028}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: If645e738b4a5800eceabd993738ac2285f4a63bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8196
Reviewed-on: https://chromium-review.googlesource.com/1233834
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56031}
Currently, wasm memory and wasm code use a shared limit for the total
size of reservations. This can cause wasm code reservations to fail
because wasm memories used all available reservation space.
This CL introduces a soft limit which is used when allocating wasm
memory with full guards. If this limit is reached and the respective
flag is set, we fall back to allocation without full guards and check
against the hard limit. Code reservations always check against the hard
limit.
R=ahaas@chromium.org
Bug: v8:8196
Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
Reviewed-on: https://chromium-review.googlesource.com/1233614
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56028}
The JSTypedArray instance is created early on in the TypedArray
constructors, using EmitFastNewObject, which puts Undefined into
all slots. But the code might still produce an exception afterwards
leaving the JSTypedArray in a weird state. It's not a security issue
since the object doesn't escape, but it confuses the heap verifier.
Bug: chromium:885404, v8:4153, v8:7881, v8:8171
Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7
Reviewed-on: https://chromium-review.googlesource.com/1233257
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56019}
This is the next step to support large array buffers. On 64-bit archs
the full safe integer range is available (up to 2^53-1 bytes in theory).
On 32-bit platforms the full Unsigned31 range is allowed, so that we can
continue to use CheckBounds for typed arrays and data views in the
optimizing compiler (it's generally unlikely that the kernel will give
you more than 1GiB of contiguous memory anyways).
Drive-by-fix: This introduces proper chokepoints for the byte_offset
and byte_length accesses in the CSA code, and also does some renaming
for consistency.
Bug: v8:4153, v8:7881, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e
Reviewed-on: https://chromium-review.googlesource.com/1228377
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56008}
If type checks in simplified lowering produced dead value (i.e., of
type Type::None()), we have only propagated deadness along value
edges. With this CL, we also insert an Unreachable node after every
effectful node that produces dead value.
This is more consistent with dead code elimination, which also inserts
unreachable nodes after effectful nodes with value output None.
Bug: chromium:884052
Change-Id: Idcb168461f05f1811b2c9c16ab8ff179b259fbd3
Reviewed-on: https://chromium-review.googlesource.com/1228125
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55987}
Word8 and Word16 representation is treated like Word32 for the sake of
TurboFan's representation selection, but this was missing from the
Word64 conversions.
Bug: chromium:884933, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: If7b69cdd02b12546d87bba0643e9ee9cb35cb299
Reviewed-on: https://chromium-review.googlesource.com/1229953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55983}
This is a reland of a4105a437d
Original change's description:
> [wasm] Implement handling of exported/imported exceptions.
>
> This implements the proper semantics for matching exported/imported
> exceptions by using the notion of an "exception tag" that is global to
> the system. It can be used to match exceptions in one module against
> exceptions declared and/or thrown in another module (or instance).
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-shared
> BUG=v8:8091
>
> Change-Id: I37586d7be5d5e6169b3418dfbc415b26dd4750dd
> Reviewed-on: https://chromium-review.googlesource.com/1226976
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55940}
Bug: v8:8091
Change-Id: Ib85f099b26a8323a8a00299b5aaeb05aaff3c3c6
Reviewed-on: https://chromium-review.googlesource.com/1227975
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55959}
For NumberAdd/Subtract/Multiply we currently onlt consult the upper
bound to decide whether to compute using Int32 or Float64 operations,
whereas for NumberModulus, NumberEqual, etc. we do decide based on
the feedback types, where the only significant difference is that we
cannot promise Word32 truncations on the inputs.
This change unifies the handling for NumberAdd/Subtract/Multiply as
well, which triggers surprisingly often in our core benchmark suites..
Bug: v8:8015
Change-Id: If8ec1bc82d1e1b71285c829262a0d343a4eb2af7
Reviewed-on: https://chromium-review.googlesource.com/1226033
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55943}
This reverts commit a4105a437d.
Reason for revert: GC stress failures (https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Mac64%20GC%20Stress/3097)
Original change's description:
> [wasm] Implement handling of exported/imported exceptions.
>
> This implements the proper semantics for matching exported/imported
> exceptions by using the notion of an "exception tag" that is global to
> the system. It can be used to match exceptions in one module against
> exceptions declared and/or thrown in another module (or instance).
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-shared
> BUG=v8:8091
>
> Change-Id: I37586d7be5d5e6169b3418dfbc415b26dd4750dd
> Reviewed-on: https://chromium-review.googlesource.com/1226976
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55940}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I5ef19ea3b67f470f2d7807810110d75415ba9ed6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8091
Reviewed-on: https://chromium-review.googlesource.com/1227933
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55942}
