We no longer implement part of the debugger in JS. Therefore we can
remove the infrastructure to support this in the bootstrapper.
Also includes some drive-by cleanups.
Bug: v8:5530
R=petermarshall@chromium.org
Change-Id: I06628a559c17f99c70029fcc94848b0c78f1d3e9
Reviewed-on: https://chromium-review.googlesource.com/c/1369945
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58140}
Fix and re-enable tests for WebAssembly's memory/constructor and
table/constructor js-api.
It introduces the '[EnforceRange] unsigned long' algorithm used
to validate initial and maximum properties.
The initial property is now required, by the switch to the Web IDL
specification. Most of the input validations errors are now considered
TypeError instead of RangeError.
The WasmTableObject and WasmMemoryObject APIs use more consistently uint32_t
to ensure integer range and remove the need for bounds checks.
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: v8:8319
Change-Id: Iedd3ee6484ef688a5e96f93006eb6ca66d805a48
Reviewed-on: https://chromium-review.googlesource.com/c/1354043
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58138}
This implementation currently only supports the optimized tier.
Bug: v8:7747
Change-Id: Ia1af29b11a5d3e8a48b122f6cf3240c9f5948bfb
Reviewed-on: https://chromium-review.googlesource.com/c/1364710
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58137}
Just pass a pointer to the current stack. This makes it easier to reuse
the {DoReturn} method for breaks to the outermost block.
R=titzer@chromium.org
Bug: v8:8423
Change-Id: Ide8533b154daa227e044820bb9c181f836ba654a
Reviewed-on: https://chromium-review.googlesource.com/c/1370028
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58132}
MIPS32 doesn't have instructions to properly handle 64-bit atomic
instructions.
Skipping those test on MIPS64 simulator because they have flaky
TIMEOUT on buildbots.
Change-Id: I31511dfce70a933b9326a7c270509c5f31af743a
Reviewed-on: https://chromium-review.googlesource.com/c/1367450
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Predrag Rudic <prudic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#58125}
This is a reland of 9c2c8f15f8
Original change's description:
> [wasm] Support encoding s128 simd types in exceptions.
>
> This adds support for having simd type values (i.e. s128) stored in an
> exception. It is the natural combination of the simd propsal and the
> exception handling proposal.
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8390
>
> Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
> Reviewed-on: https://chromium-review.googlesource.com/c/1363141
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58098}
Bug: v8:8390
Change-Id: I333c50cd766055f74b023df626d0fd90fdef3bac
Reviewed-on: https://chromium-review.googlesource.com/c/1370024
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58122}
This reverts commit 9c2c8f15f8.
Reason for revert: New test crashes: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux/28948
Original change's description:
> [wasm] Support encoding s128 simd types in exceptions.
>
> This adds support for having simd type values (i.e. s128) stored in an
> exception. It is the natural combination of the simd propsal and the
> exception handling proposal.
>
> R=clemensh@chromium.org
> TEST=mjsunit/wasm/exceptions-simd
> BUG=v8:8390
>
> Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
> Reviewed-on: https://chromium-review.googlesource.com/c/1363141
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58098}
TBR=mstarzinger@chromium.org,gdeepti@chromium.org,clemensh@chromium.org
Change-Id: Iedcfba36af925249131a2b0e9aebd92321ae72f5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8390
Reviewed-on: https://chromium-review.googlesource.com/c/1367808
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58102}
This adds support for having simd type values (i.e. s128) stored in an
exception. It is the natural combination of the simd propsal and the
exception handling proposal.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-simd
BUG=v8:8390
Change-Id: I01079f82a6ba4d9152de4dae63e3db1584ca7cd8
Reviewed-on: https://chromium-review.googlesource.com/c/1363141
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58098}
This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint.
RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed,
and may causes nested Microtasks in a problematic way. E.g. that confuses
v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext().
OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it
respects the microtask suppressions.
As all existing tests don't call RunMicrotasks() in the suppressed situation
(like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should
not affect to these tests.
Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d
Reviewed-on: https://chromium-review.googlesource.com/c/1360095
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58068}
Currently, if we lower to a pure computation that is unreachable because
of some runtime check, we just rename it with DeadValue. This is
problematic if the pure computation gets later eliminated - that allows
the DeadValue node float above the check that makes it dead. As we
conservatively lower DeadValues to debug-break (i.e., crash), we
might induce crash where we should not.
With this CL, whenever we lower an impossible effectful node (i.e., with
Type::None) to a pure node in simplified lowering, we insert an
Unreachable node there (pinned to the effect chain) and mark the
impossible node dead (and make it depend on the Unreachable node).
Bug: chromium:910838
Change-Id: I218991c79b9e283a9dd5beb4d3f0c4664be76cb2
Reviewed-on: https://chromium-review.googlesource.com/c/1365274
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58066}
Make sure WebAssembly's js-api exposes the correct attributes: writable,
enumerable and configurable.
Bug: v8:8319
Change-Id: I427533159d7975a42c0c5cb1babdc8a61f8198b5
Reviewed-on: https://chromium-review.googlesource.com/c/1351002
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58053}
The existing implementation embedded an isolate-specific pointer to the
thread-in-wasm flag in the wrapper code. However, when the module code
is shared among multiple workers, this can mean that the workers
share the same thread-in-wasm flag.
With this change we load the pointer to the flag at runtime from the
current isolate. Thereby the correct flag is used even when the same
code is executed on different workers.
Note that we could access the right flag address by going through the
root register. However, changing the code generation to use the root
register requires some inconvenient steps:
* Pass the isolate to the pipeline again, which we don't want.
* Change the WasmCallDescriptor to allow the use of the root register
for wrappers but not for other code.
To avoid these issues, and allow the CL to be easy to merge back, we
got for the changes proposed here.
R=mstarzinger@chromium.org, ishell@chromium.org
Bug: v8:8533
Change-Id: If15565a7ad7cba835cfc1628e7a4d3fdef90a5c0
Reviewed-on: https://chromium-review.googlesource.com/c/1358518
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58044}
Taking kSystemPointerSize into account when determining the maximum
allowed BigInt size accidentally made the limit platform-specific.
This patch chooses a platform-independent constant (1<<30) instead.
Bug: chromium:909614
Change-Id: I4717969bc56e6dd5f1eed70b7e60e621989d0719
Reviewed-on: https://chromium-review.googlesource.com/c/1355625
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57983}
The optimized code for TestSetWithCustomIterator holds a weak reference to the map
for the entries object. If this is collected by the GC then the optimized code deopts
which causes the test to fail. To prevent this, hold onto an entires object to keep
it's map alive.
Change-Id: I5796e74fc1d7c5061bf8c98f7a82fe582d6be76a
Reviewed-on: https://chromium-review.googlesource.com/c/1357043
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57978}
Add the arm architecture to the list of archs that support
Liftoff in mjsunit and so run the Liftoff tests for it.
Bug: v8:6600
Change-Id: I4896f0727f6ccc3343f5d517e100840f76dd901d
Reviewed-on: https://chromium-review.googlesource.com/c/1357040
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57976}
The placement of the exceptipon section is by now restricted to be in
between the Global and the Import section. This changes our validation
to check this stricter requirement now.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70
Reviewed-on: https://chromium-review.googlesource.com/c/1356504
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57962}
This is a reland of 9436e8a817
This CL simplifies the wasm/futex.js test so that it doesn't push the
limits of d8.
Original change's description:
> [wasm] Add I64AtomicWait implementation
>
> Bug=v8:8075
> R=adamk@chromium.org,binji@chromium.org
>
> Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/1342948
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57917}
Change-Id: Ifd26f1ecdb9fe24a1896162bb4d4285f9188a9ba
Reviewed-on: https://chromium-review.googlesource.com/c/1351304
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57953}
Bug=v8:8075
R=adamk@chromium.org,binji@chromium.org
Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
Reviewed-on: https://chromium-review.googlesource.com/c/1342948
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57917}
This constant is unused, and should never be used, since name sections
are encoded as an unknown section with the special name "name".
R=ahaas@chromium.org
Change-Id: I2fa1a21506dbe30033aecb3c1bf9ad84b6b872bc
Reviewed-on: https://chromium-review.googlesource.com/c/1352305
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57905}
This avoids leaving the heap in an invalid state if a GC occurs during
population of the cloned property array, as is done in other IC
builtins.
BUG=chromium:904167, v8:7611
R=jkummerow@chromium.org, ishell@chromium.org
Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940
Reviewed-on: https://chromium-review.googlesource.com/c/1350282
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57879}
The {setTableLength} method is redundant and has a single user. Remove
it, use {setTableBounds} instead.
Drive-by: Add default to the table max, to document that this can
actually be {undefined}, in which case the table has no maximum.
R=binji@chromium.org
Bug: v8:8238
Change-Id: I0d7a2f4d49d083f7adadbb4b6cd4933bcb1dc174
Reviewed-on: https://chromium-review.googlesource.com/c/1350126
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57860}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
We cannot assign a meaningful type to Promise#catch() or
Promise#finally(), since they both return whatever the invocation of
'then' on the receiver returns, and that is monkeypatchable by arbitrary
user JavaScript.
Bug: chromium:908309, v8:7253
Change-Id: Ib15f81c366938a1b1f10be6c6af85c1f3374b898
Reviewed-on: https://chromium-review.googlesource.com/c/1350789
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57828}
This is a reland of a5336471f2
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
Bug: v8:8021
Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2
Reviewed-on: https://chromium-review.googlesource.com/c/1346630
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57798}
Rather check expressions used as patterns directly. Check parentheses by
tagging parenthesized expressions as parenthesized.
This allows us to drop UnexpectedPatternToken and makes it clear why a specific
token is unexpected (because it's invalid in a binding pattern).
This also more uniformly restores messages like "Invalid destructuring
assignment target".
Change-Id: Idd98e9116c85de4c2304cf1fef1baa097b67149d
Reviewed-on: https://chromium-review.googlesource.com/c/1349572
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57792}
Instead, simply track it as a valid binding pattern. To do this in the case of
parenthesized formals, we delay throwing the binding pattern error for
parenthesized (and async "calls") until we know it's not an arrow function head
by itself.
This guarantees that if an arrow head is a valid binding pattern, it's either a
valid parenthesized head or a valid identifier, or invalid pattern ("array" or
"object" literal style). We can detect the latter case by checking that the
current token is not a RPAREN and the expression isn't an identifier.
(Alternatively we could check that the curren token is RBRACE or RBRACK...)
Bug: chromium:907575
Change-Id: Ie40cc3235d3188f2620b6c089a0f49d93604dda6
Reviewed-on: https://chromium-review.googlesource.com/c/1348078
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57743}
Many tests were already skipped in debug mode, but they kept running on CQ
which sets dcheck_always_on, probably equally slow.
Some other tests are marked as slow based on a recent run of the arm64 sim
trybot.
NOTRY=true
Bug: v8:7783
Change-Id: Ic022518edfa112ea6d228ae9a68653c99651dbb4
Reviewed-on: https://chromium-review.googlesource.com/c/1347479
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57724}
This CL moves optimization capabilities from typed lowering to typed
optimization. In particular, this allows retyping of Speculative to
number optimizations depending on their input types. This can save type
checks if we know that inputs are already in SafeIntegerRange and uses
are truncating to 32bit integers.
This change recovers the performance lost to 31bit Smis on
Octane/crypto on x64:
32bit nosmis avg 30,984.84 stddev 180.52
31bit smis (w/o patch) avg 29,438.52 stddev 120.30 -4.99%
31bit smis avg 31,274.52 stddev 176.26 +0.93% +6.24%
Change-Id: I86d6e37305262336f4f7bd46aac0d2cbca11e8c1
Bug: v8:8344
Reviewed-on: https://chromium-review.googlesource.com/c/1323729
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57717}
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
since that is called when we are compiling the native context independent SharedFunctionInfo
and the WasmModuleObject requires a native context. Instead save the members required to
create the object in the AsmWasmData and create it during module instantiation. Note:
since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
this doeesn't have semantic change for asm.js code.
As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
struct. Some logic is also moved from module-compiler to wasm-engine to make the
seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
BUG=chromium:900535,v8:8395
Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
Reviewed-on: https://chromium-review.googlesource.com/c/1345509
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57704}
Load elimination is running together with to dead code elimination, the
latter of which might eliminate allocations (in particular FinishRegion
nodes). These are treated as alias nodes by load elimination, and load
elimination does not immediatelly learn that a node has been disconnected.
This causes load elimination to access the inputs of dead code eliminated
nodes while resolving renames, which causes nullptr dereferences.
This CL modifies load elimination to not resolve to a nullptr alias but
simply stop before that.
Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5
Bug: chromium:906406
Reviewed-on: https://chromium-review.googlesource.com/c/1346491
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57688}
This reverts commit a5336471f2.
Reason for revert: Fails nosnap debug tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21838
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
TBR=danno@chromium.org,caitp@igalia.com,tebbi@chromium.org
Change-Id: Id0cd8b16131f151a42dffbaca7e59ab17c68ab23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8021
Reviewed-on: https://chromium-review.googlesource.com/c/1346116
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57677}
Adds the Object.fromEntries() method behind
--harmony-object-from-entries.
Includes an initial implementation of the new experimental builtin
Object.fromEntries implemented by Daniel Clifford, and
has been modified by Caitlin Potter to support a fast case to skip
the iterator protocol when it can be done unobservably in common cases.
There are some incidental changes: A number of CSA macros have been
updated to use TNodes, and some Context arguments have been
re-arranged to be implicit in Torque.
There are also a number of mjsunit tests written mirroring and
expanding on the test262 tests.
BUG=v8:8021
Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
Co-authored-by: Daniel Clifford <danno@chromium.org>
Co-authored-by: Caitlin Potter <caitp@igalia.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1337585
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57667}
This is a reland of 585b4eef6a without
any changes.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> 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}
Tbr: bmeurer@chromium.org
Bug: v8:8015
Change-Id: I32e5c2f439a1186891ca3393ee53a2a766585839
Reviewed-on: https://chromium-review.googlesource.com/c/1345993
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57664}
Previously the simplified operation `Number.min(x,y)` would lower to
`Select(Float64LessThan(x, y), x, y)` which would yield `y` when both
`x` and `y` are zeros, specifically when `x` was -0 and `y` was +0.
For `NumberMin` we need to use `Float64LessThanOrEqual` since we
generally allow -0 on the left hand side (in SimplifiedLowering).
Bug: chromium:906870
Change-Id: I25ae8fb19608b77c90ed130e69d9d9fa93fcea9d
Reviewed-on: https://chromium-review.googlesource.com/c/1342920
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57633}
This reverts commit 585b4eef6a.
Reason for revert: Speculative, crbug 906567.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> 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}
TBR=sigurds@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8015
Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
Reviewed-on: https://chromium-review.googlesource.com/c/1340253
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57602}
Fail IsInvalid check if the property cell has been invalidated.
Bug: chromium:905555
Change-Id: Ia0712b97bd6ba628936b74b3893ddb1c229ee686
Reviewed-on: https://chromium-review.googlesource.com/c/1339863
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57597}
GC needs to be able to read a bigint's length while the main thread may
change the length and the sign (bigints are intentionally mutable as
long as they haven't escaped to user code). Since both values are stored
in the same bitfield, we need to make these accesses atomic.
Also change right-trimming to not insert a filler when the object is
in large object space (it makes no sense there).
Bug: v8:8440
Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975
Reviewed-on: https://chromium-review.googlesource.com/c/1337737
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57576}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
With just five cache registers, Liftoff can run out of memory on a
64bit shift. This CL solves this by using a parallel register move and
pinning less registers.
R=ahaas@chromium.org
Bug: chromium:894307
Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce
Reviewed-on: https://chromium-review.googlesource.com/c/1337580
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57552}
When one of the inputs to NumberMin or NumberMax is NaN we need to
return NaN, ignoring whatever else was passed. Specifically we cannot
lower `NumberMin(x,y)` to `(x < y) ? x : y` if `x` can be NaN. So
limit this optimization to only perform the above lowering if we
know that `x` is an OrderedNumber and `y` is a PlainNumber (or if
the difference between zeros doesn't matter, an OrderedNumber as
well).
Bug: chromium:905457
Change-Id: If05f19255e14789ab0e277e072469c40e161b85b
Reviewed-on: https://chromium-review.googlesource.com/c/1337576
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57535}
This fixes several problems with instanceof and constant field tracking
in the compiler:
- properly bailout on numbers and non-functions at @@hasInstance.
- deopt on changes of @@hasInstance property.
Bug: v8:8361
Change-Id: I4a1cf9e29d72076f2d37a7c703f18cb2fb8f4040
Reviewed-on: https://chromium-review.googlesource.com/c/1322449
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57532}
This updates fast path checks in string's search/match/replace/split/matchAll
methods.
Bug: v8:8361
Change-Id: I0377aff21e380d6c718e7471f8964e10c030281b
Reviewed-on: https://chromium-review.googlesource.com/c/1333668
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57509}
An oversight in my previous change (3b64764b1d) could
cause a CHECK failure.
Bug: chromium:904707
Change-Id: Ie5f1c500bddc00741b889f78ae9ecd9af581ba5c
Reviewed-on: https://chromium-review.googlesource.com/c/1333409
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57459}
Previously, the following call sequence was always made when creating resulting
subsetted TypedArray:
1) TFJ TypedArrayPrototypeSubArray
2) TFS TypedArrayConstructor
3) TFS CreateTypedArray
This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is
safe to use (IsPrototypeTypedArrayPrototype and
!IsTypedArraySpeciesProtectorCellInvalid).
Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement...
BEFORE
TypedArrays-SubarrayNoSpecies(Score): 1033530
TypedArrays-SubarrayNoSpecies(Score): 1018490
TypedArrays-SubarrayNoSpecies(Score): 1037030
AFTER
TypedArrays-SubarrayNoSpecies(Score): 1439030
TypedArrays-SubarrayNoSpecies(Score): 1417540
TypedArrays-SubarrayNoSpecies(Score): 1405980
Bug: v8:7161
Change-Id: I356dace36570aa161ffe208a57a80e46714121a2
Reviewed-on: https://chromium-review.googlesource.com/c/1331154
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57458}
It's not sufficient to check the NoElements protector because that
doesn't guard against the array having a custom prototype.
Bug: v8:8449
Change-Id: I843815466a1e4ae197a2b76eec62d04cdc2d619d
Reviewed-on: https://chromium-review.googlesource.com/c/1332232
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57457}
This matches the pre-torque behavior when the receiver's length
was greater than the max array length.
Bug: chromium:902672
Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203
Reviewed-on: https://chromium-review.googlesource.com/c/1330921
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57456}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}
I just ran into this when creating a test case. The huge spread caused
a RangeError (stack overflow). It's not causing problems for the tests
we currently have, but let's fix it anyway.
R=ahaas@chromium.org
Change-Id: Ib67f059f2981ccc6239ba4ae05611e20eb3aa191
Reviewed-on: https://chromium-review.googlesource.com/c/1329177
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57429}
Now that we have no more do-expressions, we don't need to reparent variables
and declarations anymore. However, it's still possible that temporaries were
implicitly allocated. We still need to move those.
Bug: chromium:904255
Change-Id: Ia8a90eb822b9db123ffb0bad58e4b720c1452d9f
Reviewed-on: https://chromium-review.googlesource.com/c/1329685
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57424}
Split the Install methods into PrepareInstall and Install, such that
all heap mutations (besides the actual installation) are done in
PrepareInstall and only the actual installation in Install. This
ensures that the code object in question doesn't get deoptimized while
we're still installing its dependencies.
Bug: chromium:903697
Change-Id: I4da97d89d0707fa3c00c97c092af0d0faa7a4946
Reviewed-on: https://chromium-review.googlesource.com/c/1329162
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57419}
This test was adapted from a repro, and thus it's rather complex.
It takes over seven minutes to run on the arm64 sim debug bot,
and nearly five minutes on arm.
Given that it was originally accompanied by a very targeted fix in
Crankshaft, it strikes me that this probably isn't worth our CPU
time to continue running.
Bug: v8:7783, chromium:85177
Change-Id: Ibe85cc254aa754365404b5fbbf80bcb1f5a09c68
Reviewed-on: https://chromium-review.googlesource.com/c/1327188
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57408}
The flag is on by default, so we don't need to specify it. More
importantly, the tests are expected to work for any value of that flag.
So don't force the flag but use whatever the test variant chooses.
Note that in streaming-compile.js, the flag was accidentally specified
as '-async-compilation'. I also removed that one.
R=ahaas@chromium.org
Change-Id: Ifad31160d266dda38cdd9dd1d73dad69bd2c2f2c
Reviewed-on: https://chromium-review.googlesource.com/c/1325961
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57406}
Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`,
but this will yield the wrong results when `x` is a subnormal, i.e.
really close to 0.
In CSA we already perform bit checks to test for -0, so teach TurboFan
to do the same for comparisons to -0 (via `Object.is`). We introduce a
new NumberIsMinusZero simplified operator to handle the case where
SimplifiedLowering already knows that the input is a number.
Bug: chromium:903043, v8:6882
Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4
Reviewed-on: https://chromium-review.googlesource.com/c/1328802
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57382}
Behavior in Release mode was correct; Debug mode triggered a DCHECK
failure that indicated an inefficiency: when a requested truncation
would be a no-op, we should return the original BigInt, rather than
creating a copy. In the special case of -2^(n-1), i.e. the smallest
negative n-bit integer, getting truncated to n bits, with n being a
multiple of kDigitBits, this shortcut was not taken.
Bug: v8:8426
Change-Id: I8e4595d9ac0dbef81aae06688f9a9636bd2d9cd9
Reviewed-on: https://chromium-review.googlesource.com/c/1325029
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57369}
Change the macros added in bf84766a2c to
only do the hard work if FLAG_unbox_double_fields is unset (otherwise,
they will attempt to dereference raw float64s, which is bad!)
Also adds a write barrier in CopyPropertyArrayValues for each store if
it's possible that a MutableHeapNumber is cloned.
BUG=chromium:901301, chromium:902965, chromium:903070, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org, ishell@chromium.org
Change-Id: I224d3c4e7b0a887684bff68985b4d97021ba4cfb
Reviewed-on: https://chromium-review.googlesource.com/c/1323911
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57368}
Since we use a ScopedPtrList to track cover grammar expressions we don't know
the position of the commas anymore. The position of the commas was used to
demark the initializer, which is needed to figure out whether we need hole
checks for variable references. (Typically only references within the
initializer need hole checks for the initialized variable.) Since we didn't
have the comma position, we simply used the position of the first expression as
the position of any subsequent comma, which would make it seem as if the
initializer body wasn't in the initializer. Now instead we simply use the
position of the subsequent parameter as the end of the initializer, which is
close enough.
Bug: chromium:902810
Change-Id: I8d2bc7a2dc9f59db16ce56ccef01e263a18a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/1326022
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57357}
The Ignition statement list visitor will skip the rest of the
statements in the list if it hits a jump statement (like a return
or break), as the rest of the code in the list can be considered
dead.
return;
dead_call(); // skipped
However, since this is at an AST node level, it does not take into
account condition shortcutting:
if(2.2) return;
dead_call(); // not skipped
There is also a second dead code elimination in Ignition compilation, at
the bytecode array writer level, where a bytecodes are not emitted if an
"exit" bytecode (Return, Jump, or a few others) has been written, until
the next basic block starts (i.e. a Bind).
This can cause an issue with statements that resurrect the bytecode
array writer part-way through their visit. An example is try-catch
statements, which save the context to a register, and then Bind to start
the try region.
For the case:
if (2.2) return;
try { // try statement not skipped
...
}
the bytecode writer is called with
OutputReturn() // exit bytecode seen
OutputMove(<context>, r1) // not emitted
Bind(&try_begin) // starts new basic block
// try body
So, the try is emitted, but without saving the context to a register.
This means that the liveness analysis sees the read of that register
(as the output liveness of throwing bytecodes), but does not have a
write to the register, which means that the liveness escapes.
This patch fixes this by using the bytecode array writer dead-code
elimination (i.e. "exit bytecode seen") to inform the statement list
visitor, so that in this example the try statement is not visited at
all.
Bug: chromium:902395
Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1322951
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57350}
As opposed to the register.
For subtle reasons, this fixes a deoptimizer bug with handling return
values in lazy deopt. Since the return values can now only overwrite
the accumulator, there is no danger of overwriting a captured object
that might be later used (since there is no "later").
Bug: chromium:902608
Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
Reviewed-on: https://chromium-review.googlesource.com/c/1325901
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57349}
Installation of the PrototypePropertyDependency, as well as GC, can
invalidate dependencies.
Bug: chromium:902552
Change-Id: Iabcce026c7475c722d19ac0b80758b22d9fbcfda
Reviewed-on: https://chromium-review.googlesource.com/c/1322450
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57343}
regress-336820 is testing that joining a very sparse
array to create a too-big string results in a RangeError,
rather than a crash. Reducing the largest index by
two orders of magnitude speeds this up (on x64 debug)
by 8x (from 8 seconds down to 1). Given that this test
takes nearly 9 minutes on arm64 sim debug, I hope to
see big ones there too.
Bug: v8:7783, chromium:336820
Change-Id: I74c22cf451a892eb039efc7f1259152921bf8530
Reviewed-on: https://chromium-review.googlesource.com/c/1323915
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57335}
Recursion is really only useful for sloppy eval and with scopes, which are
uncommon.
Change-Id: I2560b600cab9b00a82d5837a3daa28c8d38c2959
Reviewed-on: https://chromium-review.googlesource.com/c/1322451
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57316}
Adds a helper macro "CloneIfMutablePrimitive", which tests if the
operand is a MutableHeapNumber, and if so, clones it, otherwise
returning the original value.
Also modifies the signature of "CopyPropertyArrayValues" to take a
"DestroySource" enum, indicating whether or not the resulting object is
supplanting the source object or not, and removes all default
parameters from that macro (which were not used anyways).
This corrects the issue reported in chromium:901301, where
StaNamedOwnProperty was replacing the value of a MutableHeapNumber
referenced by both the cloned object and the source object.
BUG=chromium:901301, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org
Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
Reviewed-on: https://chromium-review.googlesource.com/c/1318096
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57304}
'simulator_run' is now used exclusively in test/*/*.status.
Change-Id: I501b7ffd19e2476f4c803ed3d25cba69d67039fa
Reviewed-on: https://chromium-review.googlesource.com/c/1318610
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57300}
This test currently takes nearly 10 minutes on the arm64 debug builder.
Bug: v8:7783
Change-Id: I500fc026b01873e666f32062d790eca3f34455b9
Reviewed-on: https://chromium-review.googlesource.com/c/1318495
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57298}
simulator takes too long to run.
Change-Id: I77f6e932129bfed7d1cdb7e9ccf78a4608554ff5
Reviewed-on: https://chromium-review.googlesource.com/c/1320389
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57296}
Rename variables and flag names so that the classes can be reused
by private methods implementation.
In particular:
Rename "fields" to "members" in the initializer so that we can
initialize both fields and private methods/accessors there,
for example:
instance_fields_initializer -> instance_members_initializer
InitializeClassFieldsStatement -> InitializeClassMembersStatement
Rename "private field" to "private name" for the private symbols
used to implement private fields so that we can use them to
store private methods/accessors later as well, for example:
private_field_name_var -> private_name_var
NewPrivateFieldSymbol -> NewPrivateNameSymbol
The follow-on is in
https://chromium-review.googlesource.com/c/v8/v8/+/1301018
The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing
Bug: v8:8330
Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe
Reviewed-on: https://chromium-review.googlesource.com/c/1312597
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57289}
These tests are also used for streaming. This CL changes the test to
actually output the exception that unexpectedly happened.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Ia9c91a7d3d9452f9c0180329a5434f049b56c3c8
Reviewed-on: https://chromium-review.googlesource.com/c/1319755
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57284}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
This should allow for better parallelization when running these tests.
Change-Id: Ib3cae7d6e8f0d2608470ca616eeac7eecae3b7ab
Reviewed-on: https://chromium-review.googlesource.com/c/1318094
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57256}
- Add the WeakRef class and its deref() function.
- Add WeakFactory.prototype.makeRef
- Implement the "keep during job" behavior for WeakRef constructor and deref().
- Here we keep the targets alive longer than until the end of the job
(microtask), contradicting the spec. However, this is probably the indended
behavior, see https://github.com/tc39/proposal-weakrefs/issues/39 .
BUG=v8:8179
Change-Id: I41990d41ac1799e34f675d8431b9a7aa7ed3d48d
Reviewed-on: https://chromium-review.googlesource.com/c/1306435
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57242}
This is a reland of 7bd9eb7e1e. No changes
to that patch other than adding a test case. The bug that lead to the
revert has been fixed in 9bf8f72c5b.
Original change's description:
> Add fast paths to Array.from.
>
> This reuses the fast path from IterableToList for Array.from. The fast
> paths are taken when .from is called with the receiver Array and the only
> argument is the iterable (no mapping function or thisArg).
>
> Bug: v8:7980
> Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746
> Reviewed-on: https://chromium-review.googlesource.com/c/1297322
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56993}
Bug: v8:7980
Change-Id: Id081837946c0989ec2b31ce991f48d09e0219b09
Reviewed-on: https://chromium-review.googlesource.com/c/1317586
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57240}
The fast paths for sets and maps did not support allocation in
large object space, yet they were taken in these cases. This CL
adds support, simply by passing the kAllowLargeObjectAllocation
argument to AllocateJSArray.
It also changes the fast path for strings to use this argument
rather than take the slow path.
Bug: v8:7980, v8:8410
Change-Id: I18e88cb4ceb7ebeca250edd8b8b0eb401fdbd6e4
Reviewed-on: https://chromium-review.googlesource.com/c/1317507
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57232}
- Avoid allocating AstRawString in the preparser
- Use fast LiteralEquals to compare the directive.
Bug: chromium:901250
Change-Id: I178aca812f6c0ffa28d7f48b707316a5a99a2ac0
Reviewed-on: https://chromium-review.googlesource.com/c/1314570
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57217}
Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
We didn't check if the input typed array was neutered before going to
the fast path, so we hit a CHECK in this case.
Fix this by just checking if the buffer was neutered and then going to
the 'check iterator' case if it is. This will cause a TypeError via
IterableToList, which was the same as the behavior before the
optmization was landed.
Bug: chromium:899519
Change-Id: I09e6389ea2ab1e3bef01e616721b48a9b66c1b2a
Reviewed-on: https://chromium-review.googlesource.com/c/1307422
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57137}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
BinaryNumberOpTyper was not monotonic: if one input changes
from Number to Numeric, while the other input stays BigInt,
the result would change from Number to BigInt.
We have some fuzzing tests for monotonicity but unfortunately
they never generated the inputs required for triggering this bug.
We'll look into improving our tests.
Bug: v8:8380
Change-Id: I7320d9ae4b89ad8798bf9e97cc272edba2162a77
Reviewed-on: https://chromium-review.googlesource.com/c/1307418
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57125}
These tests rely on dropping references to objects either explicitly ("o =
null;") or implicitly ("o goes out of scope") and then doing gc. It's essential
that we haven't already marked the WeakCell pointing to o and marked it alive
before dropping the reference.
BUG=v8:8179
Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c
Reviewed-on: https://chromium-review.googlesource.com/c/1306437
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57115}
This adds appropriate LoopExit nodes for the JSCallReducer lowerings of
the following higher order Array builtins:
- Array.prototype.every()
- Array.prototype.find()
- Array.prototype.findIndex()
- Array.prototype.some()
Loop peeling allows TurboFan to make loop invariant operations in the
callback passed to the higher order builtin fully redundant, and thus
completely eliminate the loop invariant code from the subsequent loop
iterations. This can have a huge performance impact, depending on what
kind of code runs inside of the callback. For example, on the micro-
benchmarks outlined in http://crbug.com/v8/8273 we go from
forLoop: 364 ms.
every: 443 ms.
some: 432 ms.
find: 522 ms.
findIndex: 437 ms.
to
forLoop: 369 ms.
every: 354 ms.
some: 348 ms.
find: 419 ms.
findIndex: 360 ms.
which is 20% improvement, and essentially brings the Array builtins (the
appropriate ones Array#some() and Array#every() in this case) on par
with the hand-written `for`-loop.
Bug: v8:1956, v8:8273
Change-Id: I9d32736e5402807b4ac79cd5ad15ceacd1945681
Reviewed-on: https://chromium-review.googlesource.com/c/1305935
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57110}
This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.
The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.
The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.
This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from
testDataViewGetUint8: 796 ms.
testDataViewGetUint16: 997 ms.
testDataViewGetInt32: 994 ms.
testDataViewGetFloat64: 997 ms.
to
testDataViewGetUint8: 895 ms.
testDataViewGetUint16: 889 ms.
testDataViewGetInt32: 888 ms.
testDataViewGetFloat64: 890 ms.
meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.
Design-Document: http://bit.ly/turbofan-word64
Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
Reviewed-on: https://chromium-review.googlesource.com/c/1303732
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57095}
For NumberMin and NumberMax we don't need to go to Float64 when the
inputs are known to be in SafeInteger range, instead we can go to
Word64 on 64-bit architectures. This is preliminary work for the
huge DataView support, since we'll utilize NumberMax in that case
to clamp the limit for the bounds check.
Bug: v8:8178, v8:8383
Change-Id: I414114229c5c86b92749d30d645cedc641541ae4
Reviewed-on: https://chromium-review.googlesource.com/c/1304535
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57090}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
This fixes the fall-back case when parsing a multiplicative expression
where the lookahead found a '-' token followed by an unsigned token, but
no '*' token is following. We cannot rewind both tokens, but still need
to make sure that a full multiplicative expression is parsed.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-8377
BUG=v8:8377
Change-Id: I20ce6267445b32bdaf03f41f11d9ef4be66cb636
Reviewed-on: https://chromium-review.googlesource.com/c/1304317
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57084}
- Store dirty JSWeakFactories in a heap root (not native context) -
during GC there's no native context necessarily.
- Schedule one microtask per JSWeakFactory.
- Enter the context of the cleanup function before calling it.
BUG=v8:8179
Change-Id: Icaa245a08a60dd7325af828858ebe55d842c5bf6
Reviewed-on: https://chromium-review.googlesource.com/c/1298899
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57081}
This allows very large arrays being joined to incrementally,
on-demand allocate the internal buffer. Previously, join
would allocate the buffer upfront and all at once. Large,
sparse arrays will use less memory.
Bug: chromium:897404
Change-Id: Id914b14a7c55a62834f63ad602bdb45363249075
Reviewed-on: https://chromium-review.googlesource.com/c/1303538
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57075}
While not strictly necessary, this is consistent with how
SlowFlagGetter behaves. It adds an additional shift operation (which
we could fold into the smi untagging if needed).
Drive-by: Typify flag accessors.
Bug: chromium:899464
Change-Id: Ib154d626e522ed723e2c19b1ab7f68560ac414bc
Reviewed-on: https://chromium-review.googlesource.com/c/1304315
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57063}
When replacing a LoadElement with variable index with its known fields,
only do it if the types match, otherwise we end up with a graph that
representation selection cannot handle. That can only happen in dead
code, but TurboFan would nevertheless crash in representation selection.
Bug: chromium:893982, chromium:899524, v8:5267, v8:6200
Change-Id: I01e645d5e01bffb911d216d37d923792d9d0beab
Reviewed-on: https://chromium-review.googlesource.com/c/1303721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57059}
In order for Error.prepareStackTrace() to be able to reconstruct the
same stack frame that the internal mechanism can, we need to also
expose the index for the Promise.all() builtin. The newly added
CallSite#getPromiseIndex() does exactly that.
Bug: v8:7522
Change-Id: I904a4c1005f539536a71926ea1da38b31e2a2e8a
Reviewed-on: https://chromium-review.googlesource.com/c/1304293
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57055}
The assumption behind this optimization was invalid. Even if the
string's prototype is unchanged, the symbol could exist somewhere
further up the prototype chain.
GetProperty has been sped up significantly so it might be fine to just
skip this fast path. An alternative would be to use a protector cell.
Bug: v8:8357
Change-Id: Ia577107a58157350eb15780c02aa63d77e600637
Reviewed-on: https://chromium-review.googlesource.com/c/1301498
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57038}
This just adds calls to SerializePrototype right before we access the
serialized prototype. Eventually we need to do this earlier.
Bug: v8:7790, chromium:899115
Change-Id: I597e95f5f6df8aae608ee295fe9550e7c2a45e6d
Reviewed-on: https://chromium-review.googlesource.com/c/1301475
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57034}
The valid store types of a {Float64Array} heap view are specified to be
"float?" and "double?". We correctly accepted both types but forgot to
emit the appropriate conversion in the "float?" case. This just adds the
missing conversion expression.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-898974
BUG=chromium:898974,v8:8347
Change-Id: I306b10e2088185b1522da29b1a113908ef9925f2
Reviewed-on: https://chromium-review.googlesource.com/c/1301499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57025}
This adds support for Promise.all() to --async-stack-traces (also at
zero cost, since we can derive the relevant information from the resolve
element closure and context). In case of `Promise.all(a)` the stack
trace even tells you which element of `a` is responsible, for example
```js
async function fine() {}
async function thrower() { await fine(); throw new Error(); }
async function test() { await Promise.all([fine(), thrower()]); }
```
will generate the following stack trace
```
Error
at thrower (something.js:1:9)
at async Promise.all (index 1)
at async test (something.js:3:3)
```
so it not only shows the async Promise.all() frames, but even tells the
user exactly that the second element of `[fine(), thrower()]` is the
relevant one.
Bug: v8:7522
Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45
Reviewed-on: https://chromium-review.googlesource.com/c/1299248
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57023}
Currently, because the source float_64_array has an iterator, it hits
the code in the "check_iterator" section of TypedArrayFrom which calls
IterableToList. This builds a temporary PACKED_ELEMENTS array (and boxes
all of the numeric values as HeapNumbers), then uses this as the source
array.
This patch checks if the source array is a TypedArray, and if the iterator
is the built-in one (where we know the iterator's behaviour). If both are
true then it bypasses the creation of this temporary array and uses the
original TypedArray as the source.
This allows it to take advantage of the existing fast code for copying one
typed array to another.
R=hablich@chromium.org, petermarshall@chromium.org
Bug: chromium:884671
Change-Id: I19a944c9d6d5d07699c7dc3ad7196fc871200b62
Reviewed-on: https://chromium-review.googlesource.com/c/1297312
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57022}
This skips big-object-literal on bots with dchecks (setting DEBUG) and with
stress mode in general.
NOTRY=true
Bug: v8:8328
Change-Id: I53480d1ee942d2c83e46c8804bd8920a5e36cad2
Reviewed-on: https://chromium-review.googlesource.com/c/1301495
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57017}
Checking impl()->IsAsync(identifier) is insufficient since it could be
parenthesized. By checking the token in addition to IsIdentifier guarantees
that we've only seen the single token ASYNC.
Bug: chromium:898812
Change-Id: Id94dd607381050b4bd8cd6d8672a5d11256db7da
Reviewed-on: https://chromium-review.googlesource.com/c/1300134
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57013}
This also disables the test on tsan bots and on bots that have
dchecks always enabled, which includes try bots.
Bug: v8:8332, v8:8831
Change-Id: Ib52cd32985d50e89ddfdc525f08f60ddfd981f1e
Reviewed-on: https://chromium-review.googlesource.com/c/1297319
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57000}
This adds support for having reference type values (i.e. anyref) stored
in an exception. It is the natural combination of the reference type
proposal and the exception handling proposal.
Note that this also introduces support for having write barriers in
generated WasmCode, as this is the first time we are storing references
within generated code. Such write barriers will be needed for other uses
of reference types (e.g. mutable global) regardless.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref
BUG=v8:8341
Change-Id: I1211d4a850954622cb873eede0b4024fecc3dd8b
Reviewed-on: https://chromium-review.googlesource.com/c/1296484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56995}
This CL allows ExtractFixedArray to know if the JSArray has only Smi
elements. In that case ExtractFixedArray will always skip write barriers
when copying the Smi-only backing store. In the case that the copying
is not possibly conflicting with the concurrent marker, CopyElements will
efficiently use memcpy for further performance.
This improves the performance of ExtractFastJSArray and CloneFastJSArray.
As a result, performance of copying Smi arrays by slice() and spreading is
improved, except for spreading Smi holey arrays.
Bug: v8:7980
Change-Id: Ie39f8abf3b5039cc12a8ca7ece81352375e0e9da
Reviewed-on: https://chromium-review.googlesource.com/c/1286340
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56989}
PrepareElementsForSort must return a number less than or equal the array
length.
Bug: chromium:897512, v8:7382
Change-Id: If5f9c4d052e623ab9f3300b8534603abbee859fa
Reviewed-on: https://chromium-review.googlesource.com/c/1297958
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56982}
BuildClassBoilerplate accessed the native context to get the
class_function_descriptors. Baseline compilation should be native context
independent, so we shouldn't access the native context at all. As it happens,
class_function_descriptors wasn't used so can just be removed.
BUG=chromium:898076, v8:8041
Change-Id: If9c0edf3dfde68c76ea87820f9d4b080aac6d60e
Reviewed-on: https://chromium-review.googlesource.com/c/1298033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56958}
This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.
TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:
```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
ObjectIsUndetectable(right)
else
ReferenceEqual(left, right);
```
This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from
naive: 2946 ms.
tenary: 2134 ms.
to
naive: 2230 ms.
tenary: 2250 ms.
which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).
This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is
```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 14 bytes, whereas the `tenary` function generates
```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.
Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}
This is a reland of ec969ea3b1
Temporarily removes high memory usage test.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> 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@{#56907}
Bug: chromium:897404
Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223
Reviewed-on: https://chromium-review.googlesource.com/c/1297675
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56946}
Previously StringToList use the length of the original string, which is
not the right value: we expect the length of the new array to be the
number of characters (codepoints).
Bug: v8:7980
Change-Id: I2efca5715323c4399cb45c53871ae349207f3458
Reviewed-on: https://chromium-review.googlesource.com/c/1297320
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56944}
Because of ordering issues we didn't set the wire bytes on the
{NativeModule} during {OnFinishedStream}. We then failed during
instantiation when trying to read the import names from the wire bytes.
This CL fixes this locally without much code churn. I plan to clean up
the interaction between {AsyncCompileJob} and {AsyncStreamingProcessor}
in a follow-up CL.
R=ahaas@chromium.org
Bug: chromium:898310
Change-Id: I06337a04ba380f87b803f325323208298d363f41
Reviewed-on: https://chromium-review.googlesource.com/c/1296467
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56938}
This CL introduces proper Oddball and ReceiverOrOddball states for the
CompareOperationFeedback, and updates the StrictEqual IC to collect this
feedback as well. Previously it would not collect Oddball feedback, not
even in the sense of NumberOrOddball, since that's not usable for the
SpeculativeNumberEqual.
The new feedback is handled via newly introduced CheckReceiverOrOddball
and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
Just like with the Receiver feedback, it's enough to check one side and
do a ReferenceEqual afterwards, since strict equal can only yield true
if both sides refer to the same instance.
This improves the benchmark mentioned in http://crbug.com/v8/8356 from
naive: 2950 ms.
tenary: 2456 ms.
to around
naive: 2996 ms.
tenary: 2192 ms.
which corresponds to a roughly 10% improvement in the case for the
tenary pattern, which is currently used by dart2js. In real world
scenarios this will probably help even more, since TurboFan is able
to optimize across the strict equality, i.e. there's no longer a stub
call forcibly spilling all registers that are live across the call.
This new feedback will be used as a basis for the JSEqual support for
ReceiverOrOddball, which will allow dart2js switching to the shorter
a==b form, at the same peak performance.
Bug: v8:8356
Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
Reviewed-on: https://chromium-review.googlesource.com/c/1297309
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56925}
The assertion was intended to verify that the function is only called
at appropriate times (at a point when it was called both by by other builtins, and by desugarings added in the parser and during bytecode generation) --- However, it didn't account for the case where
the wrapper Promise is resolved with another JSPromise with a
non-callable "then" method. (Step 12 of
https://tc39.github.io/ecma262/#sec-promise-resolve-functions):
"If IsCallable(thenAction) is false, then
Return FulfillPromise(promise, resolution)."
It would be observable to verify this behaviour by loading the "then"
value and asserting that it's non-callable, so instead the CSA_ASSERT
is just removed and replaced with a comment explaining the appropriate
use of the function.
BUG=chromium:897436, v8:5855
R=bmeurer@chromium.org
Change-Id: Ib4b11abfe3339409b57ccfda9c3f75a34e0db532
Reviewed-on: https://chromium-review.googlesource.com/c/1296909
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56916}
This reverts commit ec969ea3b1.
Reason for revert: test fails consistently on arm bots.
I can't repro the failure locally, but it does consume ~512MB of memory (for a single string, I think?), so my guess is that the bots don't have enough contiguous address space.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> 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@{#56907}
TBR=danno@chromium.org,peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I8ca80bd75833aacc94ccb25ceb82bbc8880991db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:897404
Reviewed-on: https://chromium-review.googlesource.com/c/1297471
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56915}
- Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
- When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
- Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
- Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
Bug: chromium:897404
Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
Reviewed-on: https://chromium-review.googlesource.com/c/1293070
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@{#56907}
Whenever left-trimming is possible (e.g. whenever user code is
called), we must not store a reference to an exposed JSArray's
elements.
Bug: chromium:897366,v8:7382
Change-Id: I8dd6a93aa6ed19e755ccce7122e0e019dc578a31
Reviewed-on: https://chromium-review.googlesource.com/c/1292066
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56903}
This is to fix test262 tests which expect that there is no arguments
object.
Bug: v8:7186
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56205c29609666dc832297e4d36a4d487eae36cc
Reviewed-on: https://chromium-review.googlesource.com/c/1291469
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56890}
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}
