In JSStackFrame::GetMethodName() we try to infer a useful method name to
show for the closure to which the stack frame belongs. This is done by
first considering the functions name, and checking if the receiver has a
property with that name and if that property's value is the closure. In
case the function doesn't have a name or the property's value is not the
closure itself, we fall back to a reverse lookup of the closure within
the object (and its prototypes).
This CL speeds up this logic by attacking two problems:
1. The reverse lookup was performed by first using the KeyAccumulator to
extract the names of all enumerable properties, and afterwards using
the LookupIterator on each name, and testing the resulting property
value against the closure. This is fairly slow and creates a lot of
temporary objects and handles. We now look into the descriptor arrays
or dictionary backing stores of the objects directly instead, which
is easily 2-10x faster.
2. For the common case of `o.foo = function() { ... }` the parser already
places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
which we can use as a hint to infer the name of the function instead
of immediately falling back to the expensive reverse lookup.
This repairs the regression reported in http://crbug.com/1069425 and
recovers most of the slowdown reported in http://crbug.com/1077657
(there's still some overhead left from the async stack trace tracking).
Fixed: chromium:1069425
Bug: chromium:1077657
Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72545}
This is a reland of 6ada6a90ee
- Fixed a GC issue
https://bugs.chromium.org/p/v8/issues/detail?id=11335:
GC expected all arguments on the stack from code with
CodeKind::TURBOFAN to be tagged objects. This is not the case now with
inlined Wasm calls, and this information can be passed in
SafepointEntry for each call site.
- Disabled JS-to-Wasm inlining for calls inside try/catch.
For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
Bug: v8:11092
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests).
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
> generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
In the latest spec, catch_all is encoded as 0x05. This is the same
opcode as "else", but they do not conflict because "else" is not valid
in the context of a try block.
The 0x0a opcode now corresponds to the "unwind" instruction, which
currently has the same semantics as "catch_all".
R=clemensb@chromium.org
Bug: v8:11392
Change-Id: Ie9cd06c9a2001a02d8bea5be7a3c016e3a58ee3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674007
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72531}
For dictionary mode objects, whether or not a property is constant was
not tracked before. This CL makes the required non-Turbofan changes,
guarded behind the new flag V8_DICT_PROPERTY_CONST_TRACKING.
In addition, prototypes are not converted to fast mode objects if this
flags is enabled.
Bug: v8:11247
Change-Id: Ia5942733239a97560b6efc015f0e25a35fea3d7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566757
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72524}
There is a bug in the top-level await spec draft such that async
strongly connected components are not always evaluated before their
depending modules.
See https://github.com/tc39/proposal-top-level-await/pull/161 for full
discussion and spec fix.
Bug: v8:11376
Change-Id: I88bf06afb2e9a5d8d0b757de8276f1d1242a875e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667772
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72508}
When constant-folding the test based on static types in the function
body decoder, we have to ensure Liftoff's value stack is properly
updated.
Fixed: chromium:1172912
Change-Id: I618992608882b850a8a4bce0b267ce456e4c2a40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664447
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72482}
Optional chain checks check if the object is null or undefined and
if it is we don't perform the load but just load accumulator with
undefined. For calls the value of the accumulator needs to be stored
in the callee register. We were doing this only when the object
isn't null or undefined. This cl fixes it by storing it to callee
always.
Bug: chromium:1171954
Change-Id: I391af18e783486fed70be561027bd8aba97b93cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2665466
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72475}
This is a reland of commit 9c09c227b0.
The fix for gc stress failure is merged: https://crrev.com/c/2656857.
Original change's description:
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
Bug: v8:11331
Change-Id: I82f57b3fe5f0c456472aa7ce404703f34b73d17e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659511
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72465}
Bug: v8:11353
Change-Id: Iba5b6a2740a5fca55c5f4cee53367fb6413ba3d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659635
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72441}
The delegate instruction is invalid in the following cases:
- When the target is not a try block or the function block,
- When the instruction is inside a catch handler of the target.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ic59e8314982166863ba2078e2b3b39e3ba488a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656318
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72428}
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property
accurately. When "eval" is seen, figure out whether it can access
"super" and if yes, set the corresponding home object as needed.
Fix 2: The object literal scope shouldn't be entered for things
inside spreads.
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72422}
PostMessage of an ArrayBuffer that is not detachable should result
in a DataCloneError.
Bug: chromium:1170176, chromium:961059
Change-Id: Ib89bbc10d2b58918067fd1a90365cad10a0db9ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653810
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72415}
They've started failed, and no work is planned for the foreseeable
future.
Bug: v8:8888
Change-Id: I89dfa8f972a5bffa2bbb09c7a6ca56a0c4da9a02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656316
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72407}
ALmost all tools have migrated to .mjs modules.
Bug: v8:10667
Change-Id: I95f7c4a31a721be3000c990bdac1c4eb0779b693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642460
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72404}
This reverts commit f6450b97ec.
Reason for revert: ClusterFuzz bugs
Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}
TBR=marja@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
Instead of updating the detected features set directly, use the
synchronized {OnCompilationStopped} method.
In order to avoid this error in the future, the whole
{detected_features()} getter is removed, as it returns a pointer which
can only be accessed when holding the mutex anyway. Also, the refactored
code was the only user of this dangerous method.
Drive-by: Pass the WasmFeatures set by value, since it's just an
EnumSet.
Drive-by 2: Remove a print line from the regression test which can be
confusing if the test is picked up again by foozzie.
R=ahaas@chromium.orgCC=zhin@chromium.org
Bug: v8:11357
Change-Id: I75b5c8f35983d2bc1fd2b61adcb2ecfc18564f39
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653226
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72375}
Currently, feedback vectors are allocated on a fixed budget of 1024.
In some cases it might be beneficial to allocate feedback vectors based
on invocation count rather than fixed budget. For example, if we have
a large function that is only run once. This cl adds an option to
use interrupt budget based on the bytecode size. It kind of mimics
invocation count. We would allocate feedback vectors early when we
have loops which is also required.
This flag is turned off by default. In followup cl, we will enable it
and if the memory / performance tradeoff is good we might make it
default.
Change-Id: I9f7231119b5fd65fb3268e665e2e315fb2625e1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584960
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72371}
Bug: chromium:1170261
Change-Id: Id2c5d18df892ece2823f7784dee4e69e54b7454c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652491
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72368}
The bot is pretty red, so skip the test until we have a fix.
TBR=zhin@chromium.org
Bug: v8:11357
Change-Id: I38bad23ba66518f95de0f13017a6b408623a519d
No-Try: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652493
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72363}
The GC requires all slots in a stack frame that store a reference to be
aligned. This alignment was not provided for spill slots in OOL code.
R=thibaudm@chromium.org
Change-Id: I17492362318623aecc4c54635407d0c8badf3d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72324}
This change completes support for import assertions for dynamic import().
A new version of the HostImportModuleDynamically callback taking import
assertions is added to the public API. The name is very verbose; we
could consider removing the "ImportAssertions" part when the old API
is removed.
Bytecode generation is updated to pass the assertions, if present, to
Runtime_DynamicImportCall.
Isolate::RunHostImportModuleDynamicallyCallback extracts the assertions
from the options bag, filters out the assertions not present in the
list specified by the host in HostGetSupportedImportAssertions, and
sorts them by code point order of the keys per
https://tc39.es/proposal-import-assertions/#sec-import-call-runtime-semantics-evaluation.
The resulting array is passed to the host in the callback.
Bug: v8:10958
Change-Id: I931df00f954a9f9c65bff5bcf461ba1c8f11e94e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620578
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72307}
This CL implements the upcoming spec change:
https://github.com/tc39/proposal-regexp-match-indices/pull/49
A new JSRegExpResultWithIndices subclass is introduced with a separate map and
an extra slot for storing the indices. If /d is passed, exec() constructs a
JSRegExpResultWithIndices and eagerly builds indices.
The existing re-execution logic is removed.
Bug: v8:9548
Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72306}
This reverts commit 9c09c227b0.
Reason for revert: gc stress failures https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/20563/overview
Original change's description:
> [wasm-simd] Merge all any_true to v128.any_true
>
> In https://github.com/WebAssembly/simd/pull/423, all any_true
> instructions were removed, and replaced with a single v128.any_true.
>
> This patch removes all but v8x16.any_true, and renames it to
> v128.any_true.
>
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
TBR=neis@chromium.org,gdeepti@chromium.org,neis@google.com,zhin@chromium.org
Change-Id: I52dbf8de679059dd7b17908c1fe3ada0eb54ff84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649240
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72305}
In https://github.com/WebAssembly/simd/pull/423, all any_true
instructions were removed, and replaced with a single v128.any_true.
This patch removes all but v8x16.any_true, and renames it to
v128.any_true.
Bug: v8:11331
Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72304}
This reverts commit 6ada6a90ee.
Reason for revert: Revert for link issue:
https://bugs.chromium.org/p/v8/issues/detail?id=11335
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests)
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
>
>
> Original change's description:
> > Faster JS-to-Wasm calls
> >
> > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
> >
> > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> > the basis of the signature of a Wasm function to call, and whose task
> > is to:
> > - set "thread_in_wasm_flag" to true
> > - convert the arguments from tagged types into Wasm native types
> > - calculate the address of the Wasm function to call and call it
> > - convert back the result from Wasm native types into tagged types
> > - reset "thread_in_wasm_flag" to false.
> >
> > This CL tries to improve the performance of JS-to-Wasm calls by
> > inlining the code of the JS-to-Wasm wrappers in the call site.
> >
> > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> > this kind of calls. A 'JSWasmCall' node is associated to
> > WasmCallParameters, which contain information about the signature of
> > the Wasm function to call.
> >
> > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> > of the Wasm function, when the conversion is not necessary.
> > The actual inlining of the graph generated for this wrapper happens in
> > the simplified-lowering phase.
> >
> > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> > lazy deoptimizations that can happen if the Wasm function callee calls
> > back some JS code that invalidates the compiled JS caller function.
> >
> > Bug: v8:11092
> > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> > Cr-Commit-Position: refs/heads/master@{#71824}
>
> Bug: v8:11092
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
> Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72147}
Tbr: ahaas@chromium.org, jgruber@chromium.org
Bug: v8:11092, v8:11335
Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72253}
On x64, reference types where not handled yet in LiftoffAssembler::push.
Note that the values pushed on the stack there do not have to be
handled by a safepoint. The reason is that stack parameters in general
are handled separately from safepoints.
R=thibaudm@chromium.org
Bug: chromium:1168116
Change-Id: Ie62479c13839f0ba240d0e41fa76d07a2cc48881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642263
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72252}
It acquires the string lock to avoid race conditions. It does so in a
slow way (by getting the isolate from the string) to avoid piping the
Isolate through.
Bug: v8:7790, chromium:1166095
Change-Id: I8b769b4e96ee780314359d1d15d712012aade88a
Fix: chromium:1166095
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637861
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72236}
Previously ShouldHaveBeenSerialized() would return false for
kPossiblyBackgroundSerializedHeapObject objects which prevented
checks for whether the correct serialization had been done before
accessing Map::prototype() for these ObjectRefs.
BUG=chromium:1168435,v8:7790,v8:9684
Change-Id: I31b4cf7c7ce67ba1c46aea1451172b279d215508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640479
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72215}
The inlining of JS-to-Wasm wrappers can fail inside try/catch because
the IR built by WasmWrapperGraphBuilder::BuildJSToWasmWrapper does not
always set the correct control outputs in the call node.
This patch disables inlining inside try/catch to work around this issue.
Bug: chromium:1168386
Change-Id: I1b43bdb044b38d95c2d309290e228a86ba1513a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639927
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72191}
The bytecode offset (previously 'bailout id') was referred to as 'ast
id', 'node id', 'bailout id' in different spots. And 'bailout id' was
used to refer to deoptimization exits. This CL makes used terms more
consistent.
Bug: v8:11332
Change-Id: I2b34c7d4ebf465939e18fdfba675d83852f2430a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639756
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72190}
This is a reland of 8703c38d9a
The reland marks the new test as slow, skips all variants, and
skips all non-release modes.
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
Tbr: neis@chromium.org, solanes@chromium.org
Bug: chromium:1034322
Bug: v8:9534
Change-Id: I28a23d0cc4b14d59c3d4a5dbadd5dab3ac31d442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639753
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72183}
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.
2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).
3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.
4) MultipleEntryBlockContextScope was messing up the accumulator
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
The test was explicitly tiering up or down a module, without respecting
other isolates. Thus it was failing in multi-isolate mode.
This CL removes two runtime functions which do not make sense in a
multi-isolate setting (and were only used in this one test), and
replaces them with runtime functions that mimic what enabling/disabling
the debugger domain does: As long as there is at least one isolate which
needs modules to be tiered down, we keep them tiered down.
R=thibaudm@chromium.org
Bug: v8:10359, v8:10099
Change-Id: Ia85f4ea29ba6a6bb54aca54a48fadd351121d3eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637231
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72164}
This reverts commit 8703c38d9a.
Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview)
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org
Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1034322
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72158}
This CL extends the smarter function-entry stack check logic (see
v8:9534) to OSR'd code. These smarter stack checks prevent
overflowing the stack during deoptimization.
The challenge for both function-entry (FE) and OSR-entry (OE) stack
checks is that there is no dedicated physical StackCheck to
deoptimize into. For more context: the physical StackCheck bytecode
was removed in crrev.com/c/1914218.
FE stack checks solve this by using a marker bailout id to signify
a deopt bytecode offset before the first bytecode.
In this CL, OE stack checks take a similar approach by using the
OSR'd loop's JumpLoop bytecode, which is conceptually immediately
before the OSR'd loop header.
When a stack overflow at an OE stack check occurs: %StackGuard
may cause a lazy deopt on return to the optimized OSR code,
causing re-execution of the JumpLoop handler in the
InterpreterEnterBytecodeAdvance builtin, ultimately continuing
execution the interpreter at the first bytecode of the OSR'd loop
header.
Bug: chromium:1034322, v8:9534
Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72153}
If a register is used for both input and output by a SAME_INPUT_OUTPUT
operand, then it represents a different virtual register for the end
use-position of an instruction (since that will become the output's
virtual register). It therefore can't be used to represent the input
virtual register for any input operands that are USED_AT_END.
BUG=chromium:1163715,v8:9684
Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72149}
StateValuesAccess iterates over actual (non-adapted) arguments, thus
we must be careful not to iterate past their end when handling rest
args and advancing through the initial non-rest-args.
Tbr: neis@chromium.org
Bug: chromium:1167709,chromium:1166136
Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72145}
This reverts commit 4d5b878b61.
Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263
Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}
TBR=marja@chromium.org,leszeks@chromium.org
Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
There was a bug that only the last local with a reference type got
initialized to null, all other locals kept the initial value of 0. This
CL fixes this bug.
Additionally this CL optimizes the code slightly. Before this CL, the
null reference was loaded from the instance for every local with
reference type. Now the null reference is cached after the first load
and then used for all other locals.
R=thibaudm@chromium.org
Bug: chromium:1167587
Change-Id: Ic11fc76b650e6daa029491154744fc132778f70d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632695
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72139}
FrameState parameters must not be iterated directly since parameters
can be encoded into StateValues (i.e. parameter i is not necessarily
InputAt(i)). Instead, they should be accessed through the
StateValuesAccess helper class.
One example:
82: StateValues[sparse:^^^^^^](81, 31, 32, 33, 34, 35)
81: StateValues[sparse:^^^^^^^^](110, 24, 25, 26, 27, 28, 29, 30)
31: NumberConstant[8]
32: NumberConstant[9]
33: NumberConstant[10]
34: NumberConstant[11]
35: NumberConstant[13]
Here, node 81 holds multiple parameters. These are properly iterated
by the StateValuesAccess class.
Bug: chromium:1166136
Change-Id: I12725f83994e1c05571bcba153ff45154b16d93f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625879
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72126}
This reverts commit 3a6f75ac94.
Reason for revert: performance regressions https://bugs.chromium.org/p/chromium/issues/detail?id=1163063
Original change's description:
> [objects] Remove MakeExternal case for uncached internal strings
>
> Concurrently accessing internal external uncached strings is not
> thread-safe. We are removing a case where we can make such a string
> through MakeExternal.
>
> Bug: v8:7790
> Change-Id: I958062c15cf40ccc330600bb572de98620866e54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71573}
TBR=leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I5dcc734869c3c921eacd89426309141127a85f47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633547
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72123}
There is an implication from --predictable => --single-threaded =>
--no-wasm-tier-up. This implication introduces conflicting flags for
all tests that set --wasm-tier-up. This CL disables all these tests.
R=machenbach@chromium.org
Bug: v8:11319
Change-Id: I32452d74ae33fc0e081971c5c0ed840334f274d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632598
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72119}
Exception ref is not part of the latest exception handling
proposal. Remove the corresponding value type, the type opcode and some
obsolete tests.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I5e068ba3426f4b56b90ef056193acdd8cc8fe7d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632599
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72116}
Offsets in regular expressions are limited to 16 bits.
It was possible to exceed this limit when emitting greedy loops where
the length of text nodes exceeded 16 bits, resulting in overflowing
offsets.
With this CL we throw a SyntaxError "Regular expression too large" to
prevent this overflow.
Bug: chromium:1166138
Change-Id: Ica624a243bf9827083ff883d9a976f13c8da02e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629286
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72095}
Changes:
- Add --wasm-loop-unrolling flag. Everything in this CL happens behind
this flag.
- In decoding, DoReturn does not take returned values as an argument.
It is now the responsibility of graph-builder-interface.cc to extract
these values. Note that this is what was already happening in Liftoff.
- In pipeline.cc, add phase to remove loop exits after generating the
turbofan graph.
- Explicitly disallow calling FallThruTo() on loops.
- Add loop assignments and loop header node to Control type in
graph-builder-interface.cc. Assign them in Loop().
- Main change: Add loop exit nodes to wasm-generated graphs. For
details, consult this design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g
- Inline PrepareForLoop().
Bug: v8:11298
Change-Id: I65058f1b5df3f862f4a62f4dcb0bd7e1f1dcf4ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621082
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72094}
This is a reland of 164cf80bbb
The reland fixes UB (left-shift of negative integer type) with a
static_cast<uint32_t>.
Original change's description:
> [regexp] Hard-crash on invalid offsets in AdvanceCurrentPosition
>
> Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
> given packed bits actually fit into 24 bits.
>
> Bug: chromium:1166138
> Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72064}
Tbr: leszeks@chromium.org
Bug: chromium:1166138
Change-Id: I514495e14bb99dfc9588fdb4a9f35d67d8d64acb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626663
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72088}
This CL prepares the WasmModuleBuilder for memory64 and adds a first
mjsunit test which executes a few memory loads and stores, some of them
trapping.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ia77c32ff0ee774665cd4bd0997c3609f6f17b80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589974
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72077}
Ext mul's codegen assumes that all inputs are in registers, but the
instruction-selector wasn't the correct constraints. The codegen for ext
mul is slightly complicated so we chose to restrict the inputs to be
registers rather than changing codegen.
Bug: chromium:1165966,v8:11262
Change-Id: I5d4eb56d17a4d0a2927b089dbf74362c7e7ff4fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626711
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72073}
Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
given packed bits actually fit into 24 bits.
Bug: chromium:1166138
Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72064}
This CL fixes a bug in the code generation for I32AtomicCompareExchange
in Liftoff on ia32. The problem is the inconsistency that
LiftoffAssembler::PeekToRegister(...) introduces to the cache state.
PeekToRegister loads the value from the value stack into a register, but
does not pop the value off the stack. When the value was already stored
in a register, the use counter of that register gets decreased, even
though the value is still on the stack.
The problem arises when this register later gets reused, which is
necessary unfortunately on ia32. When SpillRegister is called for this
register, all stack values that are stored in this register get written
to memory. SpillRegister uses the use counter of the register to detect
when the register was spilled to all stack slots that were cached by
this register. However, as described above, the value stack and the use
counter are inconsistent at that moment, so SpillRegister finishes
early and does not spill the register to all stack values, and this
causes the bug later.
With this CL the decrement of the use counter gets delayed until when
the value actually gets popped off the stack.
R=clemensb@chromium.org
Bug: chromium:1145135
Change-Id: I07cb256a7e5135dbce41b246c120650635ad2758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602464
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72018}
When creating a new closure, we check feedback vector for any optimized
code and install it on the newly created closure. We evict the optimized
code from the feedback vector if it is marked for deoptimization. We
used to evict the code before creating the new closure. However,
creating a new closure could cause allocation failures and hence trigger
a GC. This could mark optimized code on feedback vector for
deoptimization if any weak objects held by optimized code are GC'ed.
This cl delays the eviction unitl after the closure was created.
Bug: v8:1163184
Change-Id: I217279e4a51f75b87bb7ae5a00fd1cf57805e3c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613034
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71999}
We were incorrectly clearing the high reg from the list of regs to load.
The intention was to prevent double (and incorrect) loading - loading
128 bits from the low fp and the loading 128 bits from the high fp.
But this violates the assumption that the two regs in a pair would be
set or unset at the same time.
The fix here is to introduce a new enum for register loads, a nop, which
does nothing. The high fp of the fp pair will be tied to this nop, so as
we iterate down the reglist, we load 128 bits using the low fp, then
don't load anything for the high fp.
Bug: chromium:1161654
Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71976}
Now that the underlying bug is fixed, we can expect the test to always
pass.
Also simplify the test a tiny bit and skip it on debug builds because
it's slow.
Bug: chromium:1161357
Change-Id: I2ce5e064b4f707f4bd680f04df95d5a342bec1b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616220
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71972}
This implements the spec change in
https://github.com/tc39/ecma262/pull/2164
Making TA elements configurable has interaction with delete. While
the elements are configurable, they are only "deletable" via detaching
the underlying ArrayBuffer, not via `delete`. That is, `delete ta[idx]`
for an in-bounds `idx` still returns false.
Bug: v8:11281
Change-Id: I2e9348a7ec3c3239a92cc35e51b7182423736834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605234
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71955}
The flag was enabled by default in M85, it is time to remove it.
R=clemensb@chromium.org
Bug: v8:7741, chromium:1160677
Change-Id: Ic4a9490efa645a7466cb844484169ab262f0df38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610965
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71945}
Due to the transition to the jobs API, WebAssembly compilation was using
background threads, even when --single-threaded and therefore
--wasm-num-compilation-tasks=0 was used. With this CL, the compilation
job is started with a maximum concurrency of 0 when
--wasm-num-compilation-tasks=0. To ensure compilation progress in
asynchronous compilation, the main thread waits for baseline compilation
to finish right after initializing all compilation units, and thereby
participates in the compilation.
R=clemensb@chromium.org
Bug: v8:11279
Change-Id: I85f93f82c00cdbd6afd46110599089a052101a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599546
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71944}
This adds a regression test for a bug in lowering load transforms.
This test will fail if 0efa3fd97e is
reverted.
Bug: chromium:1124885
Change-Id: I31b714d4565c4fff730c1274af8059031cb1e1b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610508
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71919}
In https://crrev.com/c/2591859 we changed the way we generate code for
v128.select, which assumes that all inputs are registers. We did not
update the instruction selector with this new constraint.
Fixed: chromium:1161954
Bug: v8:11282
Change-Id: I5fc9a0315873a3e795078997d87aa92d4c8bddfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603764
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71904}
.. to verify that the trampoline_pc has been set.
Bug: chromium:1161357
Change-Id: If7e1a13cff9919e2e8a65c095d80dfcef2dc05cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606333
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71896}
Instead of looking up the specific maps in every native context, just
check against the instance type.
Bug: v8:11256
Change-Id: Ib50d599c014c95b03ba3260014dfcbd9ec82982c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593337
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71802}
Previously, we were looking up the prototype of the receiver and
checking that against %TypedArrayPrototype% before invalidating the
protector cell.
This is incorrect as it's possible to patch the prototype and then
change the constructor property, bypassing this check.
This CL adds a new instance type to prototype of all TypedArray
constructors and checks the receiver against this instance type.
TBR: tebbi@chromium.org
Bug: v8:11274, v8:11256
Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71799}
Registers are spilled differently on arm and intel platforms.
Additionally, on arm64 registers are spilled with padding. Therefore
the code for safepoint information for spilled registers is platform-
dependent now.
Additionally the alignment of the frame size is done before the
out-of-line code now, so that the safepoint indices can be calculated
correctly for spilled registers in out-of-line code.
Finally, some code was unimplemented on ia32 and arm, which I added
now.
R=thibaudm@chromium.org
Bug: v8:7581, v8:10929
Change-Id: Ia9b824dfc74cafa9ec3cc0d308fb18b485afd715
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584952
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71786}
ReduceJSToNumeric() can fail to update the node type after changing
it's operator to JSToNumeric.
BUG=chromium:1158049
Change-Id: Iaabb3676f8ad9563903b81de2e7eecdcc92cbc0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593336
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71771}
next_enumeration_index is the next free index available to store a
property. ObjectDescriptor tracks this field while instantiating the
literal and updates the next_enumeration_index when finalizing the
instantiation. When adding new properties (named / computed) we were
updating this value to the current value that is being used instead
of next free index. This cl fixes it.
Bug: chromium:1152231
Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71709}
Adds support for generating code to migrate instances if a map
is a migration target, to dynamic check maps.
BUG=v8:10582
Change-Id: Id26d95491869fc68a5633398d230237eb88648d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575058
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71658}
The implementation is follows the implementation of table.copy, aside
from the table-index being passed as an intptr instead of a Smi. The
builtins of table.get/set and table.copy are different in that regard.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: Ifde788b230083dc6633ce6b41e6acfb8b503b781
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414211
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71615}
First step towards the new exception handling proposal:
https://github.com/WebAssembly/exception-handling/issues/125
This is essentially a revert of:
"[wasm] Switch to new 'catch' and 'br_on_exn' proposal."
The changes are:
- "catch" instruction takes a tag immediate,
- "rethrow" instruction takes a label immediate,
- Add "catch_all" instruction,
- Remove "br_on_exn" instruction,
- Do not push exceptions on the stack, only the encoded values
R=clemensb@chromium.org
CC=aheejin@chromium.org
Bug: v8:8091
Change-Id: Iea4d8d5a5d3ad50693f645e93c13e8de117aa884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484514
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71602}
These tests are pretty slow with both TSAN and
--stress-incremental-marking enabled.
* Skip octane/raytrace for the variant stress when TSAN is enabled.
* Test wasm/shared-memory-worker-stress is slow with TSAN.
Change-Id: Ia4b8ce2986d04e6ef2fc7d28991cd5ce7faf31e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571129
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71598}
This is a reland of 2afb00c0e8
Original change's description:
> [heap] Remove SWEEPING phase in incremental marking
>
> The SWEEPING phase in incremental marking was used to finish sweeping
> of the last GC cycle concurrently before starting incremental marking.
> This avoids potentially long pauses when starting incremental marking.
> However this shouldn't be necessary in most cases where sweeping is
> already finished when starting the next cycle. The implementation also
> didn't cleanly separate the GC cycles.
>
> In case the sweeping phase is necessary for pause times, we can
> introduce a "CompleteSweep" phase which runs right before starting
> incremental marking.
>
> Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71555}
Change-Id: I173bdeaf342d4c0590453f7d9eeb8ab5cfddc73c
Bug: v8:11220, v8:11221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571111
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71592}
Safepoint maps record all spill slots that contain a tagged value. The
introduction of multi-value return changed the stack frame layout though
and the calculation of spill slots has not been adjusted accordingly.
This CL adjusts the creation of safepoints now to work for multi-value
returns as well.
R=neis@chromium.org
Bug: v8:11206
Change-Id: Id623dbc28b976dcf625ac78738e03e642fafbb36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569762
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71591}
Concurrently accessing internal external uncached strings is not
thread-safe. We are removing a case where we can make such a string
through MakeExternal.
Bug: v8:7790
Change-Id: I958062c15cf40ccc330600bb572de98620866e54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71573}
This reverts commit 2afb00c0e8.
Reason for revert: Some tests started to timeout.
Original change's description:
> [heap] Remove SWEEPING phase in incremental marking
>
> The SWEEPING phase in incremental marking was used to finish sweeping
> of the last GC cycle concurrently before starting incremental marking.
> This avoids potentially long pauses when starting incremental marking.
> However this shouldn't be necessary in most cases where sweeping is
> already finished when starting the next cycle. The implementation also
> didn't cleanly separate the GC cycles.
>
> In case the sweeping phase is necessary for pause times, we can
> introduce a "CompleteSweep" phase which runs right before starting
> incremental marking.
>
> Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71555}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I9adea60c21ff7cdfa7bbac3e6a4a240640fa5ea9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569766
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71570}
The {ParallelRegisterMove} at the end of {AtomicLoad} might need a
temporary scratch register for spilling values to the stack. Make sure
that one is available by giving up the scratch register used for the
address of the atomic access.
R=ahaas@chromium.org
Bug: chromium:1153442
Change-Id: I267c43e2193662c420f96f6683ebd4bbb0e1bca3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566759
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71564}
Unifies various operators for dynamic map checks with the naming
scheme of DynamicCheckMaps (to be similar to CheckMaps.
BUG=v8:10582
Change-Id: I8ac842f55fe31cdc7b84968d077017a86ddf4442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567952
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71559}
