Remove the include from js-array-buffer-inl.h, because the wasm engine
is not used in that file. Add missing includes in other files that
relied on the recursive include.
R=jkummerow@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I8b7f11ce92858cbc0ccf26925159486ed39573fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739650
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73254}
If a method happens on the main thread and only on the main thread
(i.e. it will never be run on the background), it is safer to use
non-atomic accessors as TSAN will give warnings if we use them
improperly.
As a drive-by, pass the isolate as a parameter where it was readily
available as it saves us from getting the isolate from the object later
on.
Bug: v8:7790
Change-Id: Id9bdd69254edc60b0331a32fccf1479a95b7d286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732669
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73251}
- Renames StackParameterCount to ParameterSlotCount, to avoid
confusion between slots and parameters, which are not in general
equivalent.
- Similarly, renames StackReturnCount to ReturnSlotCount.
- Adjusts the result of GetFirstUnusedStackSlot to return one more
than the last slot of the argument area, not including padding.
- Renames GetFirstUnusedStackSlot to GetOffsetToFirstUnusedStackSlot
to reflect that the result is an offset from callee to caller
frames.
- GetReturnsOffset is a little clearer, with adjustment for the
different semantics of GetFirstUnusedStackSlot.
- Renames 'optional_padding_slot' and 'first_unused_stack_slot'
variables in Tailcall codegen to reflect that these are offsets.
Bug: v8:9198
Change-Id: Ib73c52710dc1f3ead640d488a6fdeb605b7b665e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700099
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73242}
This CL is part of a series that makes SwissNameDictionary available
as a new property backing store. Currently, the flag
v8_dict_mode_prototypes allows selecting between NameDictionary and
OrderedNameDictionary as the backing store used for all dictionary
mode objects. This series of CLs changes this such that enabling the
flag causes SwissNameDictionary being used instead of
OrderedNameDictionary. The behavior for when the flag is not set
remains unchanged (= use NameDictionary).
This particular CL just collects many small changes.
Note that the changes this CL makes to literal-objects.cc do not
fix the problems with the enumeration order of computed property
names in classes that currently exist when using OrderedNameDictionary.
This will be fixed separately.
Bug: v8:11388
Change-Id: I6b98f61c395b4f2788407d6a34363ef8863cce9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735834
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@{#73224}
... to different attributes or different property kind.
Bug: chromium:1161847, v8:9233
Change-Id: I5a6e1e012c6afcf09ed9da6bbf9f33c1007c3d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727272
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73220}
This adds support for WasmGC objects (structs/arrays) to the
inspector backend. For prettier printing, it also adds support
for reading the "type" and "field" subsections of the "name"
section in Wasm modules.
This patch includes a revert of most of commit
crrev.com/987a7f4ae45ebfc986525075277debdf73001fc2 because
types are more complicated now.
Bug: v8:7748, chromium:1177784
Change-Id: Icec52cbbb32291b0e773b40be6771a678c6ec79b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73212}
This is a reland of 0c63aa9eee
Fixes the correctness fuzzing BUILD.gn breakage.
Original change's description:
> [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
>
> Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
> compression is enabled.
>
> This CL is to get performance numbers for reserving an extra register.
> There is no actual pointer cage yet, and the base register will always
> have the same value as the root register. The pointer decompression code
> is switched to using the base register instead of the root register.
>
> Bug: v8:11460
> Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73204}
TBR=rmcilroy@chromium.org,jkummerow@chromium.org,leszeks@chromium.org
Bug: v8:11460
Change-Id: Iecf6b783392a384b40ab33e0f4ce13538a8f81ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737681
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73207}
This reverts commit 0c63aa9eee.
Reason for revert: Breaking clusterfuzz builds
Original change's description:
> [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
>
> Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
> compression is enabled.
>
> This CL is to get performance numbers for reserving an extra register.
> There is no actual pointer cage yet, and the base register will always
> have the same value as the root register. The pointer decompression code
> is switched to using the base register instead of the root register.
>
> Bug: v8:11460
> Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73204}
Bug: v8:11460
Change-Id: Idebf1fc6eeeda880a21d65b6f2c674fa58690bfa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737812
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73205}
Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
compression is enabled.
This CL is to get performance numbers for reserving an extra register.
There is no actual pointer cage yet, and the base register will always
have the same value as the root register. The pointer decompression code
is switched to using the base register instead of the root register.
Bug: v8:11460
Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73204}
This is a reland of 77838343d8
No changes in this reland, this wasn't causing the failures, see
https://crbug.com/1163833 for the actual cause.
Original change's description:
> [wasm-simd] Remove add horiz instructions
>
> Bug: v8:6020
> Change-Id: I0605798d03f2e9f9c3c07c49141289889a10a3b0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727204
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73180}
Bug: v8:6020
Change-Id: I83d59ed800bd73c81cb879b4ba3a5144045c62d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733663
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73200}
This reverts commit a8b61ef521.
Reason for revert: Looks like it breaks GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/35880/overview
Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
> flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}
Bug: v8:11420
Bug: v8:11429
Change-Id: Ie71e7ce234e7b9ab9a2ec99a983e9900f35baa44
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735397
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73187}
Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
create a mapping of bytecode offset <-> sparkplug pc.
These pairs were only recorded after builtin/runtime calls.
In preparation for deoptimizing to Sparkplug, we need a more precise
mapping.
With this CL, we record positions for every bytecode. Instead of storing
a pair of (bytecode offset, sparkplug pc), we store only the pc,
calculating the bytecode offset from the index in the mapping table.
For easier use an iterator to access the mapping is introduced.
Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.
Bug: v8:11420, v8:11429
Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73186}
This is a reland of 6e234e9d76
Fix CFI by adding a BTI instruction at the start of the handler.
Original change's description:
> [wasm][liftoff][eh] Implement catch_all
>
> Inline a catch handler after each potentially throwing call. The handler
> just merges values into the actual catch environment and then jumps to
> the catch body.
>
> This automatically adds support for unwind, which also uses the
> "CatchAll" interface method.
>
> Many tests can be written either with "catch" or with "catch_all".
> Duplicate them to get coverage for both.
>
> R=clemensb@chromium.org
>
> Bug: v8:11453
> Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73129}
Bug: v8:11453
Change-Id: I84d90877e6227a1966b6347877a9c18e213d9419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732023
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73184}
When retrieving an API accessor function (i.e. either the getter or the
setter) for which the lazy accessor mechanism is used (i.e. where the
actual JSFunction is created lazily and only the FunctionTemplateInfo)
is around, we thus far created a fresh JSFunction every time the
accessor function is requested, but that's observably wrong behavior,
since the accessors are JavaScript objects with identity. We currently
rely on the instantiation cache to guarantee identity, but there's no
reason why we couldn't instead just put the instantiated JSFunction into
the AccessorPair.
Fixing this to only instantiate the lazy accessor pair only once, upon
first time it's requested, coincidentally also simplifies (and fixes)
the API accessor breakpoint machinery. This was previously lacking
support for walking dictionary prototype objects and forcibly
instantiating the lazy accessor pairs with break points. However, all
this magic in the debugger is no longer necessary when we ensure that
the lazy accessor pair component is generally only instantiated once.
Bug: v8:178, v8:7596, chromium:986063, chromium:496666
Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
Fixed: chromium:1163547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73163}
This is a wasm-only test, hence move it to the wasm directory and skip
it in no-wasm builds.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: I57c9abbb98c3415f4d759372d479e1f61464217f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731536
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73152}
These simplify production of extra information in stack traces or
dereferencing source maps in processing stack traces. While these
can be managed externally, this can be very complicated in
environments where scripts come from many different sources,
possibly not even under embedder control. Since V8 already has
easy access to this information, it's nice to share it with
embedders.
Bug: v8:11509
Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73148}
Remove sloppy-ness from the CODE_ASSEMBLER_UNARY_OP macros and the
remaining methods.
Bug: v8:6949
Change-Id: I48e2800c6bac558ae4005fa09551a4551c1dbb25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2725530
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73139}
After deprecation and removal of the old misleading API we re-add
v8::String::IsExternal which returns true for both, external one-byte and
external two-byte strings.
Bug: v8:10641
Change-Id: I4c66d4df891f7180c7a727a45c1fbd254a7f5c02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726512
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73137}
This reverts commit 6e234e9d76.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/4795/overview
Original change's description:
> [wasm][liftoff][eh] Implement catch_all
>
> Inline a catch handler after each potentially throwing call. The handler
> just merges values into the actual catch environment and then jumps to
> the catch body.
>
> This automatically adds support for unwind, which also uses the
> "CatchAll" interface method.
>
> Many tests can be written either with "catch" or with "catch_all".
> Duplicate them to get coverage for both.
>
> R=clemensb@chromium.org
>
> Bug: v8:11453
> Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73129}
Bug: v8:11453
Change-Id: Ica7fa708962d9ae4b9fbf7473963d187062227ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727266
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73131}
Inline a catch handler after each potentially throwing call. The handler
just merges values into the actual catch environment and then jumps to
the catch body.
This automatically adds support for unwind, which also uses the
"CatchAll" interface method.
Many tests can be written either with "catch" or with "catch_all".
Duplicate them to get coverage for both.
R=clemensb@chromium.org
Bug: v8:11453
Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73129}
Adds cppgc_headers to v8_internal_headers and fuzzer_support to
lib_wasm_fuzzer_common in BUILD.gn as well as v8_libbase and
v8_libplatform to cctest_headers in test/cctest/BUILD.gn.
Bug: v8:7730
Change-Id: I9759bb0993be779ddfc26668b9e08503ea53bd69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727501
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73122}
Be explicit about source positions for `Return`s in the
BytecodeGenerator, and only do self-healing explicitly in the
`ReturnStatement` translation, where an end position of
`kNoSourcePosition` is turned into the return position of the
function literal.
This allows us to reason more easily about which `Return`s actually
receive a meaningful source position, and in particular it allows us
to construct the internal `Return`s for `yield` and `yield*` with no
source position attached to them. Previously they'd get the source
position for the implicit (final) return attached to it, which confused
the debugger and led to breakpoints being set in the completely wrong
spot.
Considering the simplified example
```
function* foo(){
var a = 1;
}
```
this would previously generate the following bytecode
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
30 S> 38 : Return <=========================== internal Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
where everything between offset 4 and 42 corresponds to the implicit
yield at the beginning of every generator function, in particular the
code between 20 and 42 corresponds to that initial yields resumption
logic. Notice how the internal Return at offset 38 gets assigned the
source position of the function literal (the same as the implicit
return at the end). This confuses the debugger quite a bit when trying
to set a breakpoint on the closing brace, since it's going in bytecode
order and will thus discover the `Return` at offset 38 first (matching
the source position 30 it's currently looking for) and setting the
breakpoint there. This `Return` bytecode however is only executed when
the generator is resumed via `GeneratorPrototype.return()`, and it'll
not hit when the developer uses the generator normally, which is not
the desired behavior and extremely confusing (especially since stepping
on the other hand works as expected).
With this patch, we no longer slap a source position (and in particular
not the function literal's return position) onto these internal
`Return`s as you can see from the generated bytecode below:
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
38 : Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
This also allows us to remove the break position finding hack that was
kept in BreakIterator::BreakIndexFromPosition() for generators and
modules.
Fixed: chromium:901819
Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73119}
Split out all the headers from v8_compiler/v8_compiler_opt and
v8_base_without_compiler into v8_internal_headers since the headers
have inter-dependencies that otherwise make it impossible to satisfy gn
check.
Also adds new v8_header_set torque_runtime_support that exports
src/torque/runtime-support.h separately from the generated headers.
This reduces the number of gn check failures from 169 to 59.
Bug: v8:7330
Change-Id: Ie7ebc894910b7efa02011a74da964e11995c7f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712569
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73104}
Add a flag that crashes the process instead of gracefully handling the
abortion of evacuation. The goal of this CL is to check whether we could
get away with simply reporting OOM instead of handling this case.
Change-Id: I6a561ed007c76a111cfb85c454f7f025f07ab9cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724272
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73097}
Fixes a problem with the inlining of JS-to-Wasm call wrappers into a
surrounding exception handler and re-enables this case.
Bug: v8:11092
Change-Id: I4937838c2b4a199e21f5ac90bee5b8e8de2470be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678341
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73086}
These were prototyped and not merged into the SIMD proposal.
Bug: v8:10983
Change-Id: I5c30a0e9955ee5602e05d473f0f85be59d124205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718761
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73080}
Wasm tests and wasm fuzzers should not be compiled (and run) if
v8_enable_webassembly=false.
R=machenbach@chromium.org
Bug: v8:11238
Change-Id: I78bbb1d1d98179cac315411b8c2c2ecaee8ede91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2721761
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73071}
In https://crrev.com/c/2707170, Liftoff was changed to only store the
ValueKind instead of the ValueType, because we only need to know kind
for code emission. For debugging though, the whole type is useful.
This CL changes the debug sidetable back to store the full type, and
retrieves this information from the decoder.
R=jkummerow@chromium.org
Bug: v8:11477
Change-Id: I08a512d24cdf0955c95f3b9261d68a02a39b9b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720302
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73068}
This instruction is not in the final SIMD proposal.
Bug: v8:6020
Change-Id: Ifef1b3d58bf660f2d30784f587aed85f327825ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716073
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73058}
Change-Id: I86b0d01ed283f97cde2f3d71df68c3a75107c61d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712906
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73051}
Clean-up and slightly unify the CodeEvent tags:
* Remove INTERPRETED_FUNCTION_TAG. It was only used for interpreter
trampoline copies, which are used for
--interpreted-frames-native-stack. However, even actual bytecode
compilation doesn't use INTERPRETED_FUNCTION_TAG, so we can remove
it for simplicity.
* The tag used by the above is now the same as for the bytecode
creation event, i.e. EVAL_TAG, SCRIPT_TAG, FUNCTION_TAG or
LAZY_COMPILE, depending on whether this was a script, and eval, an
eager or a lazy compile (respectively.
* Baseline was also using INTERPRETED_FUNCTION_TAG, so now it does the
same thing as above.
* Existing code is now logged as FUNCTION_TAG rather than
LAZY_COMPILE, because we lost the laziness information.
* The SCRIPT_TAG is set based on the SharedFunctionInfo flags, not
the compilation flags, so that eager inner functions are labelled as
FUNCTION_TAG rather than SCRIPT_TAG.
Bug: v8:11420,v8:11429
Change-Id: I0286002674255ff4ba8f5d865df372a3e2975b16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713104
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73047}
Remove most dependencies on v8_wrappers. The remainder all depend on
v8_libbase anyway, so just fold it into that target which removes a gn
check error. Also removes v8_wrappers from the fuzzers where it's not
used.
Bug: v8:7330
Change-Id: I916806b62f8c49cc1d50ef493aa900e30fc623aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716383
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73041}
- Add a CFunctionBuilder interface to allow adding modifier flags
to argument types. This will be used to support IDL attributes
like [EnforceRange], [Clamp], and [AllowShared]. This CL adds
only the interface, but the actual modifier flags do not exist
yet as they would not be implemented.
- Remove the internals of the old CFunction type inference and
implement it on top of CFunctionBuilder.
Bug: chromium:1052746
Change-Id: I09a7cba07105097517a8426a8eeb891393883ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686686
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73024}
This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 .
I think it makes more sense to list ScopeInfos under "(system)" in the
dev tools, like most other V8 internal types.
Change-Id: If85f869e805d7c374fc7584a79155bb4f400e4b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707249
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73015}
Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/
Currently, wasm loop unrolling is disabled by default. We intend to
further investigate its compilation time cost and running time benefits
before enabling it.
Additional changes:
- Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight
loop analysis.
- Move EliminateLoopExit into LoopPeeling and expose it.
- Introduce loop_info_ field into WasmGraphBuildingInterface, fill it
up in Loop().
- Break after encountering the first loop in BuildNestedLoopExits.
- Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated
in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction
to be filled up by WasmGraphBuildingInterface, and then passed to
GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase.
- Introduce WasmLoopUnrollingPhase and insert it into the wasm
compilation pipeline.
- Fix an issue where exception values were not wrapped in
WasmGraphBuilderInterface.
- Update --wasm-loop-unrolling flag description.
Bug: v8:11298
Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73009}
It had essentially become a synonym for BytecodeArrayAccessor.
This removes the BytecodeArrayIterator class and renames
BytecodeArrayAccessor to BytecodeArrayIterator.
Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73005}
The precise type is only used for validation. For code generation,
knowing the kind is more than enough. Hence, only store and pass the
ValueKind in Liftoff, and not the full ValueType.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: Ia42c0fa419f75b508bd2f210c767b631e93d3398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707170
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72997}
These are headers that are used by the inspector, debugger and other
parts of chrome so they should be in the main v8_headers target.
test-api-interceptors.cc does not use anything from v8-util.h so remove
the include and some other unneeded using declarations.
Bug: v8:7330
Change-Id: Iea1546de3fc2dbc1c41f0dd7109b6c7ef5557045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716384
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72996}
This change adds a new abstract type Lazy<T> which can be used to
interoperate with CSA code that uses LazyNode. This new type has special
code-generation rules because its generated type is not TNode<...> but
std::function<TNode<...>()>. Torque code can do nothing with this type
except pass it around, but passing it to the CSA function RunLazy is an
easy way to execute the std::function and get back a normal value.
Torque code can also create Lazy<T> values using the intrinsic function
%MakeLazy, which takes the name of a macro as its first parameter,
followed by arguments to that macro which will be passed when the
LazyNode is evaluated. We use the macro's name because the language
doesn't support taking references to macros, and implementing such a
feature would be complicated.
Bug: v8:7793
Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72964}
The v8_enable_webassembly=false configuration will not be a able to run
any wasm code, hence remove the whole asm to wasm translation from the
binary.
In order to skip specific unit tests in that configuration, we move the
definition of the v8_enable_webassembly gn argument from BUILD.gn to
v8.gni, such that it is available in all gn files.
R=ecmziegler@chromium.org, machenbach@chromium.org
Bug: v8:11238
Change-Id: Id4e290df3e42ffd2f05c377bdd3a368871815daf
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712562
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72945}
This is essentially a revert of 3 commits:
- a1d39bbaed
- 5a0938e593
- 74362ae3e2
with merge conflicts fixed.
These instructions were not merged into the SIMD proposal.
Bug: v8:11297
Change-Id: Ifffe7c61cae10fadc345d0faa1b0ba45ce74e946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704950
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72933}
Also add v8_config_headers dependency to cctest_headers. This reduces
the number of gn check failures from 194 to 178.
Bug: v8:7330
Change-Id: I6453b9789503c9d8ca3ed6bbe94bce3e2a69653f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712564
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72912}
Currently if gn check is enabled (with v8/third_party ignored), there
are many errors due to headers being used without adding the proper
dependency in BUILD.gn (or because it's being used transitively without
a public_deps chain).
This makes the number of errors go from 2114 to 195.
Apart from adding dependencies, it also moves _v8_internal_Node_Print
from objects-printer.cc to node.cc so it can see the Node::Print method
which wouldn't otherwise be possible without a circular dependency. Also
removes the previously deleted compiler/graph-builder-tester.h file.
Bug: v8:7330
Change-Id: Icb34585fbef621588265cf4267cfc88ecbcf0a72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2702331
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72908}
This is a reland of 76a2ab06a1
Changes since the original CL:
- Handle unserialized elements (optional result in getter).
- Merge should_access_heap and --turbo-direct-heap-access paths.
- Slightly update the serialized path in GetOwnCowElement.
- Fix the cctest, add a regression test.
Atomic JSObject::elements/JSArray::length setters are addressed
in this CL: crrev.com/c/2704076.
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790
Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72904}
This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
Backends do not care about the concrete type, they only need to know the
"kind" (e.g. "ref" or "i32").
In order to prepare Liftoff to use the value kind instead of the
value type for all stored data, this CL moves the kind out of the
ValueType and makes it a top-level enum.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72896}
Code objects are exposed through JSFunction and SharedFunctionInfo.
If they are builtins, we don't have to worry about background threads
seeing partially initialized code objects. If they are optimized code
objects, we may. Background threads read the code fields with
AcquireLoad semantics. The fields are set on the main thread with
ReleaseStore semantics when appropriate.
Special care is taken when setting an optimized code object in a closure
in the interpreter entry stub. Since the MacroAssembler doesn't support
ReleaseStore semantics, this CL ensures that the optimized code object
is stored with those semantics in the feedback vector, where the
interpreter entry stub finds it.
Bug: v8:7790
Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72869}
We can remove some of the method definitions, as well as the
sloppy-ness from the method.
Bug: v8:6949, v8:11384
Change-Id: I04880daa3fcce097b79009f12bd24128a47c2c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690591
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72867}
This reverts commit 76a2ab06a1.
Reason for revert: A few issues, e.g.
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790, chromium:1180012
Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72860}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2688058
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72857}
This reverts commit f731e13f00.
Reason for revert: perf regressions, chromium:1179757
Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
> supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
> ScopeInfo fields by index, and move them from scope-info-inl.h to
> scope-info.cc. Those functions are still used pretty heavily during
> initialization (ScopeInfo::Create, etc.), but at least we can avoid
> presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
> It maintains the existing behavior of filling the newly-allocated
> object with undefined, even though that's not a valid ScopeInfo and
> further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
> Torque macro, because it used to rely on casting ScopeInfo to
> FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
> arrays. I think it makes more sense to list them under "(system)" in
> the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}
Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
- Remove unused type inference paths which will be replaced
with more explicit structs.
- Removes the tagged pointer from CTypeInfo since the embedder
will perform the type check for API objects.
Bug: chromium:1052746
Change-Id: I47a5f5ae35b06845b01b68cb089c67f76a7fb05e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686685
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72848}
Modify the cctests for the inlined JS-to-Wasm calls to use the
%ObserveNode intrinsic, to verify that the JSCall node is actually
inlined . This requires a small refactoring of the %ObserveNode
implementation.
Bug: v8:11092
Change-Id: I01727143fec64c6c11c58b1b664f51daae5bfdb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2677811
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72838}
There are two aspects to the non-JSObject parts of JSArrayRef:
- JSArrayRef::length. Relevant only in two spots, 1. when reading
(immutable) array boilerplates and 2. for GetOwnCowElement.
- JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
store. Relies on the invariant that cow backing stores are immutable.
This CL renames the length accessor to length_unsafe to make the
danger explicit at callsites.
For GetOwnCowElement the refactor is slightly larger, since we now
need to read into the backing store while keeping full control of
object reads (e.g. JSArray::length and JSArray::elements_kind). We
make all reads explicit at the call site by requiring that elements,
elements kind, and length are passed in as arguments to
GetOwnCowElement. Inside GetOwnCowElement, consistency between these
is *not* guaranteed due to concurrency. At runtime, consistency *is*
guaranteed through the reference-equality check on the elements seen
during compilation. The actual elements read is implemented in
ConcurrentLookupIterator::GetOwnCowElement.
Bug: v8:7790
Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72834}
ScopeInfo has a vestigial 'length' field from when it used to be a
FixedArray. This change removes that field, which saves some memory.
More specifically:
- Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
supplied the 'length' field.
- Privatize the FixedArray-style functions that provide access to
ScopeInfo fields by index, and move them from scope-info-inl.h to
scope-info.cc. Those functions are still used pretty heavily during
initialization (ScopeInfo::Create, etc.), but at least we can avoid
presenting them to the rest of the world.
- Change FactoryBase::NewScopeInfo to allocate the updated object shape.
It maintains the existing behavior of filling the newly-allocated
object with undefined, even though that's not a valid ScopeInfo and
further initialization is required.
- Move part of AccessorAssembler::ScriptContextTableLookup into a new
Torque macro, because it used to rely on casting ScopeInfo to
FixedArrayBase.
- In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
arrays. I think it makes more sense to list them under "(system)" in
the dev tools, like most other V8 internal types.
Bug: v8:8952
Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72830}
This reverts commit 2f8a7561cb.
Reason for revert: Speculative revert, lots of segfaults on Arm:
https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781
Original change's description:
> [dict-proto] C++ implementation of SwissNameDictionary, pt. 3
>
> This CL is part of a series that adds the C++ implementation of
> SwissNameDictionary, a deterministic property backing store based on
> Swiss Tables.
>
> This CL adds the initialization code, factory functions and a
> canonical SwissNameDictionary plus all helpers required for that.
>
> Bug: v8:11388
> Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Frank Emrich <emrich@google.com>
> Cr-Commit-Position: refs/heads/master@{#72824}
Bug: v8:11388
Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72829}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72824}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
During the string reverts a while back
https://chromium-review.googlesource.com/c/v8/v8/+/2633547 I reverted
some tests that were testing the code that was *not* reverted i.e. the
internalization of external strings.
Bug: v8:7790
Change-Id: I84964791cce712d753fd409cc3c641d9fbbb6550
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699262
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72809}
samples being discarded
- Passed in as CpuProfilingOptions parameter, client is responsible for
determining if function is still safe to execute. Includes unit tests
- Client (blink) side CR: https://chromium-review.googlesource.com/c/chromium/src/+/2649617,
- Client (blink) side CR requires this to be pushed prior to it being pushed
Change-Id: I3ef4640186115d4e14c1b73f902c889c776e310f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652206
Commit-Queue: Nicolas Dubus <nicodubus@fb.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72794}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
The current API returns a Handle<NativeContext> which can be
optionally null and all the users of this API never actually
checked for this null value.
Previously, this wasn't a problem as all the possible JSObjects
that were user visible would return a valid NativeContext but now
there are wasm objects that don't have a valid constructor so don't
have a NativeContext.
Bug: v8:11451, chromium:1166077
Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72769}
When there are multiple nested catch blocks, the rethrow immediate
disambiguates which catch block to take the exception from. We
add a FixedArray to keep track of exceptions that are currently
in scope, and compute the mappings between rethrow/catch instructions
and the index to fetch/store the exception from/to in the FixedArray
during pre-processing.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: If55242c551f42262c790b5bf3f1543a003280623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72768}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
Pass an explicit Isolate* argument to Compiler::Compile*, rather
than grabbing the Isolate from the function
Change-Id: I37a38103c67305077225ea3951d36007cf07beea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696655
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72762}
Same code sequence as x64.
Bug: v8:11416
Change-Id: Ibbd4cbf75e10b0ce876d42809d909868fdb86b87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686309
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72724}
This is a reland of a16add806d.
The fixes are adding disassembly for pcmpgtq and vpcmpgtq.
While fixing also noticed a mistake in assembler for pcmpgtq,
which flipped dst and src.
Also realized that we don't detect SSE4.2, so adding that in.
PS2 contains these changes.
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
Bug: v8:11415
Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72721}
As outlined in the design document linked below, we're removing the
support for the non-standard Function.displayName property for the
purpose of Error.stack and DevTools Inspector stack traces. The
motivation here is that the negative lookup is costly, and we have
Function.name as a standard alternative (configurable since ES6 for
exactly this reason).
I dediced to go with JSFunction::GetDebugName(), since
JSFunction::GetName() was confusing in that it'd only get the "name"
property's value if it's a data property, but not with accessors.
JSFunction::GetDebugName() makes it clear that this is really a debug
helper function and might not give you the "name" property value.
Doc: https://bit.ly/devtools-function-displayName-removal
Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72715}
If the exception tag does not match any of the catch blocks and there is
no catch_all block, it should be rethrown.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I8df80f51340fc6265f5ef4308ee3b0f892ee3a90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690599
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72713}
This reverts commit 87df0b7ecc (thus
relands 42cd9eb78d), with fixes for
the discovered issues.
Original change's description:
> Revert "[compiler] Directly read PropertyCells"
>
> This reverts commit 42cd9eb78d.
>
> Reason for revert: Clusterfuzz issues, e.g.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
>
> Original change's description:
> > [compiler] Directly read PropertyCells
> >
> > Main changes:
> >
> > - Introduce a new broker data kind kBackgroundSerialized for objects
> > that can be serialized in the background (when direct reads are on).
> > (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> > in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> > - Make PropertyCell use that new kind.
> > - Introduce a bottleneck in runtime code for changes to PropertyCells
> > and make sure that a certain protocol is followed that allows
> > concurrent reads from the background thread.
> > - Improve interface of PropertyCell in various ways.
> >
> > Bug: v8:7790
> > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72586}
>
> TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
>
> Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
> Bug: v8:7790
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72619}
Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72697}
Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.
Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:
1. The CaptureStackTrace() function uses the StackFrameIterator to
walk the system stack. For each native frame it uses the
FrameSummary abstraction to get all (including potentially inlined)
frames. For each of those it appends a record consisting of six
elements to a FrameArray (this holds pointers to the actual
closures and receivers).
2. Afterwards the FrameArray is shrinked to the required size, and a
new FixedArray is allocated, and initialized with new
StackTraceFrame objects where each holds a reference to the
FrameArray, the index of the frame, and an initially uninitialized
StackFrameInfo reference. This new FixedArray is then returned from
CaptureStackTrace() and either stored on a message object or
provided to the API as v8::StackTrace.
The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.
There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.
There are some notable (potentially user visible) changes:
- The CallSite#GetPosition() method now consistently returns the
Wasm module relative bytecode offset for all Wasm frames (previously
it'd return the function relative bytecode offset for non-asm.js
Wasm frames).
- The column and line numbers returned from StackFrameInfo methods are
consistently 1-based now, instead of sometimes being 0-based (Wasm)
and sometimes being 1-based (JS and asm.js Wasm). The only
potentially noticable difference is that for
CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
that was wrong and useless anyways.
- CallSite#GetThis() would sometimes return the_hole, another bug
flushed out by this CL.
The CL also contains some other not noteworthy drive-by-cleanups.
Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
UBSan starts complaining about a nullptr destination in memcpy after
https://crrev.com/c/2691828.
This CL fixes the error by not copying if there is nothing to copy.
R=nicohartmann@chromium.org
No-Try: true
No-Tree-Checks: true
Change-Id: I2c941b37d26931d6c2253bc3bb2c0aa659d4cb71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690605
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72690}
Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.
Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
When the CPU profiler receives a bytecode flush event, ensure that we
clear the appropriate CodeEntry.
Bug: v8:11054
Change-Id: I94e771e42192b75ea6d317738e4f2d5b76533dc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691826
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#72684}
- Add a no-simd-sse flag to skip SIMD tests on bots with no
hardware support.
Change-Id: I4efdbb5ee39c2e10ea8776a1f1e536ac96823efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629465
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72682}
This speeds up sparkplug by >20%.
This reland fixes the OffHeapBytecodeArray to also register a GC
callback. Turns out off-heap here doesn't mean that the underlying
bytecode array is off-heap and it can in fact move.
Change-Id: I7c6e82abd2a7be08ead537ab84855e76edc3b290
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688400
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72677}
Reasons:
* We disabled it more than a year ago for all configs
* Not easy to re-enable
* Not compatible with pointer compression as-is
* Not compatible with concurrent TP/TF as-is
* No concrete plans to re-enable it
Also remove Map's layout_descriptor since it was only used for double
field unboxing.
Bug: v8:11422
Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72671}
In the latest spec, catch can take an exception index immediate, and
control-flow jumps to the appropriate catch handler depending on the
thrown exception.
Do this by allowing multiple jump targets for the same pc in labels and
in the control transfer map. At runtime, the unwinder will choose the
appropriate control transfer entry based on the exception tag, unpack
the exception and jump to the handler.
Enable the exception cctests that were currently disabled for the
interpreter, fix some issues and add tests for the new behaviors.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I30cb8f9459647a7c6f7bfd9785b238a9c9e9fc10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690587
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72661}
Also move it from post-mvp to mvp, since it is now in the proposal.
Bug: v8:11002
Change-Id: I711ee7a92e6937948c93e6028ef018188ea4c976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676937
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72643}
This reverts commit a16add806d.
Reason for revert: Broke Win32 debug https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32%20-%20debug/29653/overview
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Idbfc8cd0fbbff607cff76953c53d0c149b87b573
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688074
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72640}
The code sequence is exactly the same as x64.
Bug: v8:11415
Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72637}
This reverts commit 60748ee2df.
Reason for revert: Broke Linux64 ASAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/38792/overview.
There are 4 changes in that range causing the failure, I found that this change caused the failure by running locally `./tools/run-tests.py --outdir=out/repro mjsunit/wasm/gc-stress --variant turboprop_as_toptier --random-seed-stress-count 100`.
Original change's description:
> Reland "[interpreter] Speed up the BytecodeArrayAccessor through direct memory access"
>
> Tbr: ulan@chromium.org, neis@chromium.org, leszeks@chromium.org
> No-Presubmit: true
> Change-Id: I4ceb9e21ac7d78a87776b4be174772539d2da8d9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685173
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72632}
TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I441ddfda5d852b7a01f38a9e60edc56f40ae626a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686266
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72635}
The implementation is similar to the callbacks that already exist for
the origin trial for WebAssembly simd.
Bug: v8:8091
Change-Id: I969b68c209ea62cf70dbaf317616300b782b5e14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672020
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72628}
Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573
I updated BasicBlockInstrumentor to use 64-bit floating-point values
rather than 32-bit integers, so that it could never overflow. However,
I've now learned that some builtins (particularly RecordWrite) are not
allowed to use floating-point registers, and so running with
basic block instrumentation enabled could produce incorrect results.
This change switches back to 32-bit integers, but adds saturation logic.
Bug: chromium:1170776
Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72626}
By disengaging it from 'let' which is not implemented in liftoff yet.
Bug: v8:7748
Change-Id: I191695767bf8c6153f70d509dd13ff734fe75e01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676631
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72620}
This reverts commit 42cd9eb78d.
Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
> that can be serialized in the background (when direct reads are on).
> (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
> and make sure that a certain protocol is followed that allows
> concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}
TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
This is a partial revert of https://crrev.com/c/2457669/.
This change is slightly longer (in code-generator-x64.cc) because we
also implement support when SSE4_2 is not supported (the reverted change
seems to assume SSE4_2, which is not always the case). This code
sequence is from https://github.com/WebAssembly/simd/pull/412.
Bug: v8:11415
Change-Id: I3eef415667b4142887cf1c449d27d19ba5bbd208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683219
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72611}
Implements https://github.com/tc39/ecma262/issues/2034
Currently the token sequence `for (async of` is ambiguous. It can be the
prefix for either `(async of => {};;);` or `for (async of foo);`. This
CL disallows the token sequence.
Note that `for await (async of` is still allowed, since there is no
C-style `for await (;;)`, and thus no ambiguity.
Bug: v8:11412
Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72607}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
Main changes:
- Introduce a new broker data kind kBackgroundSerialized for objects
that can be serialized in the background (when direct reads are on).
(I'm planning to remove kPossiblyBackgroundSerialized in a followup,
in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
- Make PropertyCell use that new kind.
- Introduce a bottleneck in runtime code for changes to PropertyCells
and make sure that a certain protocol is followed that allows
concurrent reads from the background thread.
- Improve interface of PropertyCell in various ways.
Bug: v8:7790
Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72586}
This adds support for kBool, kInt32, and kUint32 types.
Bug: chromium:1052746
Change-Id: I54641eb036eea30113c44eab2c08626176ecc40a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629463
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72574}
Those references would be passed over to Blink via buffer and dropped
after a virtual call.
Bug: chromium:1056170
Change-Id: Idd02acce7a2d5c927dd9dc2415fe507b00ff3e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682646
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72568}
Prototype these 6 instructions on arm:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
For all these instructions we rely on having Q registers that map to S
registers, which means we can only use q0 to q7. We fix the src/dst
to q0 arbitrarily.
Bug: v8:11265
Change-Id: Ied95f2dde9859a60fc216ed67615f80e9d795bb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679842
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72567}
For functions with a very large stack, the debug side table repeats a
lot of information: Most values will be spilled to the stack, still
every single entry in the debug side table repeats information about
them (type, stack offset). This leads to the size of the debug side
table to be quadratic in the size of the function.
In the linked bug, the generation of the debug side table took ~400ms,
whereas Liftoff compilation alone just took 16ms.
This CL optimized the debug side table by delta-encoding the entries,
i.e. only storing stack slots that changed. This reduces the size of the
table significantly, at the cost of making lookup slower, since that now
has to search the table backwards for the last entry that had
information about a specific slot. For now, this seems like a good
compromise. If it turns out to be a problem, we could speed up the
lookup by either forcing a full dump of the stack state after N entries,
or by dynamically inserting new entries during lookup, whenever we find
that we had to search backwards more than N entries. That would speed up
subsequent lookups then.
On the reproducer in the linked bug, this change reduces the time to
generate the debug side table from ~400ms to ~120ms.
Before this CL, the debug side table has 13,314 entries with a total of
38,599,606 stack value entries. After this CL, it shrinks to 20,037
stack value entries in the 13,314 entries (average of ~1.5 instead of
~2,899).
R=thibaudm@chromium.org
Bug: chromium:1172299
Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72558}
This requires a small fix in {Push,Pop}CalleeSavedRegisters, where
the return address was signed/authenticated at the wrong point,
which meant the stack pointer used as modifier was different from
the one the StackFrameIterator expected.
Bug: v8:10026
Change-Id: Idebd2ee8f07312b5e99dd2ea5181fc7a7e4a87bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667861
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72542}
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}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for arm64.
Bug: v8:11297
Change-Id: Ib9be5086c8ea98340c9bb1980c319626d7072c1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664994
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72537}
Implement these 6 instructions:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
The code sequences are exactly the same as on x64.
Needed to add some more instructions, and we don't have macro lists for
these instructions yet, so individually define them for now. We can
factor them into lists in a future change.
Bug: v8:11265
Change-Id: I606e1226201e3c5ecdc7e3f611315437e917d77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668913
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72535}
This CL adds PropertyDetails::ToByte and ::FromByte. These are not
applicable to all PropertDetails, but only those for dictionary-backed
properties with an (unused) enumeration index with value 0.
The motivation for this is that those dictionare backing stores that
don't store the enumeration order in the PropertyDetails but store it
in the table itself (like OrderedNameDictionary and the upcoming
SwissNameDictionary), can store PropertyDetails in an array of bytes.
Bug: v8:11388
Change-Id: Id346b924cd7c67b2f33cbc7a7807eec31cefbeec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672029
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@{#72528}
Instead of passing a bunch of objects and pointers to
{GenerateLiftoffDebugSideTable}, just pass the WasmCode pointer for
which the debug sidetable should be created.
This requires changing the corresponding cctests to actually compile
code, such that we can get a WasmCode pointer.
R=thibaudm@chromium.org
Bug: chromium:1172299
Change-Id: If42f06a545feb590f9c2377ce95e6214bbc6f566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674006
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72526}
- Stack adjustment was in slots, when it should be in bytes.
Bug: v8:11391
Change-Id: Ia791f2b637337279be62d66377f9b5be35f31839
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674062
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72515}
- Fixes some incorrect assumptions about padding in the
code generation. Slots may have apparent extra padding
when allocation fragments go unused.
- Reworks 32 bit push code to simplify skipping slot gaps
when 'push' instructions are used.
- Adds a ElementSizeInPointers function on machine
representations.
Bug: chromium:1171759,v8:9198
Change-Id: I029e300fa9c306d7e35344576fd1c68857cf2bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2660379
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72502}
Code sequence from https://github.com/WebAssembly/simd/pull/379, and
exactly the same as x64, with minor tweaks for
ExternalReferenceAsOperand.
Bug: v8:11002
Change-Id: Icbfdac62b21c2734ad4886b3d48f34e29f7a8222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664860
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72495}
We were hitting an implementation defined behavior in this instruction:
- v is clamped to uint8_t::min and uint8_t::max
- then we static_cast<int8_t>(v)
- any values that don't fit in int8_t (> 127) hits and implementation
defined behavior
We reuse base::saturated_cast here instead to avoid this undefined
behavior.
Drive-by cleanup of test cases to make the signed/unsigned cases more
explicity.
Bug: v8:11372
Change-Id: I4e92cdfb685d74bd5436ba25f1c00db49a231221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659501
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72491}
This is a partial revert of https://crrev.com/c/2457669 to add back
i64x2.ne and i64x2.all_true, which were accepted into the proposal
(https://github.com/WebAssembly/simd/issues/419).
This only implements it for x64 and arm64 on TurboFan, other archs and
Liftoff will come later.
Bug: v8:11347,v8:11348
Change-Id: I86934478760e3d501ecdb3ce6c9b702764cc0838
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2665005
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@{#72489}
We are often stepping multiple times without inspecting the state
in-between. Hence, the generated debug side table is often not being
used. Instead of always generating it, we can generate it lazily on
demand, which can avoid the need to generate it at all.
R=thibaudm@chromium.org
TEST=inspector/debugger/wasm-stepping
Bug: chromium:1172299
Change-Id: I9b9ff4485d65d720d23585856b3d672925460667
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664446
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72484}
Changes:
- Rename ObjectReferenceKnowledgs::object_must_be_data_ref to
reference_kind, introduce an enum to describe it.
- In both compilers, remove the dynamic check whether the object is an
array/struct. This is known statically. Instead, if we are checking
for a function, just check for rtt equality and exit.
- Remove is_data_ref_type(), replace it in the compilers with calls to
has_signature().
- Restructure AllocateSubRtt() to handle function rtts properly.
- Add a couple execution tests.
Bug: v8:7748
Change-Id: I46fbbfe2f2a7d29b583de0d536d71c534b98322f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661460
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72477}
The removed flags are:
1. --turbo-nci-as-midtier
2. --turbo-nci-cache-ageing
3. --turbo-nci-delayed-codegen
Flag 1. was used by a testing mode that is no longer used. Flags 2. and
3. were used to experiment with codegen and cacheing heuristics, no
longer needed now that work is suspended.
Bug: v8:8888
Change-Id: Ib4a89f09340c2d94ee7688928c8235276c1f1032
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661461
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72476}
Add comments and simpify code a bit for less chance of cargo culting.
Change-Id: Ica3fc60b0b7c11cc99a4c9ba9e3255662bbbb6bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642459
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72472}
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}
The flags are enabled by default and have stable coverage.
This also removes the corresponding bots.
Bug: v8:10315
Change-Id: Icce01383050dff758b6554db8e0c3589d6e5459c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2658324
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72457}
Changes:
- Remove an obsolete TODO from wasm-module-builder.
- Replace CHECK with gTest's EXPECT in unittests.
- Remove setting of --experimental-wasm-liftoff-extern-ref in wasm-gc.
- Test test-gc/JSAccess with Liftoff.
- Remove useless #undef's from module-decoder-unittest.
Change-Id: I11b4a3dde9683cc9c7d1eb89b1a63e1859505aad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659063
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72455}
br_on_* instructions need a precisely typed branch target, as opposed
to being treated like regular br instructions.
Bug: v8:7748
Change-Id: Iedace79faf59d61cf2ce5ac88e633e07b5a2a43f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655507
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72450}
Hosts are not supposed to rely on the ordering of import assertions list
received from V8. Thus, as a simplification, remove the sorting of the
import assertions passed to the HostImportModuleDynamically callback.
Update the corresponding test so that it doesn't require any particular
ordering of assertions.
Import asssertions for static imports will continue to be sorted. These
need to have a consistent ordering for purposes of deduplication in
SourceTextModuleDescriptor::module_requests_, so removing sorting of
these wouldn't simplify much.
Bug: v8:10958
Change-Id: I2cb07c4e68f24fa45152bf3f4321938bf94d84ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653170
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72445}
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}
As per the latest wasm-gc spec, type checks are only allowed from
subtypes of dataref and funcref. To cast from a more general type,
specialized classification instructions need to be used (will come
later).
Bug: v8:7748
Change-Id: I29de48f445d652c5fc4e266d82e7d2e32cd7b6d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649262
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72408}
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}
As per the latest wasm-gc spec, all immediate arguments are removed
from ref.cast and ref.test.
Bug: v8:7748
Change-Id: I5839103276c4c5d51f3fa82a21cf2447cbb8ecaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649261
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72405}
As per latest wasm-gc spec, the data heap type is a subtype of eq and a
supertype of all array and struct types.
The heap type expected for arrays and structs when interacting with JS
changes from eq to data.
Bug: v8:7748
Change-Id: Idd1670b9e47acc95c098559e674c629ea44ca49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649044
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72399}
As per the latest wasm-gc spec, rtts now have optional depth, with
(rtt n type) <: (rtt type) for every depth n. Liftoff compilation for
type checks without depth are not supported yet.
Bug: v8:7748
Change-Id: I4971875e6a42db6d333b61ca5e2996e875f39f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649043
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72395}
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}
vcvtdq2pd was incorrectly declared to take 3 operands, the use of the
macro Cvtdq2pd meant that the call was vcvtdq2pd(dst, dst, src). This
is an incorrect encoding. Our tests happen to pass because dst was xmm0,
which made it accidentally correct.
This fixes it by moving cvtdq2pd out of the macro list.
Bug: v8:11265
Change-Id: I8b1baf4dd2c670021eafa76dc1a10b442f812805
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2654003
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72382}
Define a new macro list, since this has 1 immediate operand (lane index)
compared to other SIMD load/stores.
Also remove all the ifdef guards.
Bug: v8:10975
Change-Id: Ib0a1f7bb6c4bdf83d81a65b4e02199b792d13837
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2645568
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72377}
Prototype these 6 instructions on arm64:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
Drive-by fix:
- f64x2.promote_low_f32x4 accesses out of bounds for the global, the
result only has 2 doubles
- fcvtn in simulator needs to clear top bits of the Q reg
Bug: v8:11265
Change-Id: Icfb3338942f0d0374448fdcfef3847a6e3ce8ff6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644066
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72373}
According to the new wasm-gc spec, ref.cast should forward a null input
without trapping.
Bug: v8:7748
Change-Id: Ifee17f02a572e7028c14482bc94f0e1c7fc82a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2647261
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72358}
This is a reland of b77deeca4b
Changes compared to original: Add explicit narrowing casts in tests
for MSVC.
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
Bug: v8:7748
Change-Id: I22b204b486fd185077cd6c7f15d492f5143f48fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650207
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72355}
Listen to code deletion events by registering finalizers on code
objects, a first stab at non-leaky long-lived code entries.
Bug: v8:11054
Change-Id: Ieaaa5b63508263bd261e8385f5bf5dd3baedf9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628587
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72342}
Multi byte values get stored on native host order when
arrays are being constructed, however as Wasm is LE enforced,
they get reversed on BE machines during simd load. This causes
incorrect values loaded into vector registers.
This CL will force mask elements to be saved in byte sizes
to eliminate endianness issues.
Change-Id: I7f2e5017664234e01fc8b51a95cdd852a418b651
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2645586
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72340}
movups is slower on older hardware (core2) than movaps, even if the
operand is aligned. (Not an issue on modern hardware).
Also move i8x16.splat(0x0F) to an external reference so we can load the
mask directly.
Bug: v8:11002
Change-Id: I0b01c27a142024d50b9faaa9e7bd6a1fe169e141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643242
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72336}
(Initially copied from nicohartmann@ CL
https://chromium-review.googlesource.com/c/v8/v8/+/2135631)
This CL adds a new intrinsic %ObserveNode(expr) which has noop semantics
but triggers the new NodeObserver set on the OptimizedCompilationInfo
when the node generated for expr is created or changed in any phase
(until EffectControlLinearization).
This provides the infrastructure to write reasonable unit tests that
check for the construction of or lowering to specific nodes (e.g.
depending on feedback).
When %ObserveNode(expr) is used an object of class ObserveNodeManager is
registered to every Reducer/GraphReducer and is notified by the Reducer
with all node changes. The same logic is added to classes
SimplifiedLowering/RepresentationSelector, which do not inherit from
class Reducer.
Observed Node modifications currently are:
* The Node Operator
* The Node type
* Node replacements
A first use case (cctest/test-sloppy-equality.cc) is included in this CL.
Change-Id: Idc5a5e38af8b1d9a2ec5021bf821c4e4e1406220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555219
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72331}
This is a reland of 5a0938e593
The fix is in instruction-selector-x64.cc, the OpParameter is a
uint8_t, I typo-ed a int8_t.
Drive-by fix to maro-assembler-x64.cc to use movaps instead of movapd.
Original change's description:
> [wasm-simd][x64] Prototype i32x4.widen_i8x16_{s,u}
>
> This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
> uses some masks and pshufb for the widening. These masks (3 for each
> instruction) are stored as external references.
>
> Bug: v8:11297
> Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72301}
Bug: v8:11297
Change-Id: Ie1df32bd4ef3c71532cab6f82a515f619b6a2b67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2648967
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72330}
Recompilation for tier down should not be triggered if the module had a
compile error. This CL ensures that by moving the recompilation a bit
later in the async compilation, to a place where a compile error would
have been detected already. An added DCHECK would catch similar bugs
earlier (crashing instead of timing out).
R=ahaas@chromium.org
Bug: chromium:1160031
Change-Id: I7eb3d2921db0f28bb39e9ec6150fd98fd4b99089
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649028
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72329}
Writing out the number of functions in the module is unnecessary. That
number is only used for validation when reading back the value, but only
validating that number is pretty arbitrary and does not protect against
bugs or attacks. Hence skip these two header fields.
R=thibaudm@chromium.org
Bug: v8:11164
Change-Id: I083075e2c8959f99690fd1478d0950a25eb7311f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644946
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72326}
This reverts commit b77deeca4b.
Reason for revert: MSVC compile fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/16535/overview
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
TBR=ulan@chromium.org,jkummerow@chromium.org,manoskouk@chromium.org
Change-Id: I2f0d97f1a34f7c81c5a97d7c37925cb84c66eea3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7748
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650206
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72322}
In the latest wasm-gc spec, rtts of abstract types are no longer
allowed. Consequently, canonical rtts of concrete types always have
a depth of 0.
Changes:
- Change the immediate argument of rtts to a type index over a heap
type. Abstract it with TypeIndexImmediate in function body decoding.
This affects:
value_type.h, read_value_type(), decoding of relevant opcodes,
wasm subtyping, WasmInitExpr, consume_init_expr(), and
wasm-module-builder.cc.
- In function-body-decoder-impl.h, update rtt.canon to always produce
an rtt of depth 0.
- Pass a unit32_t type index over a HeapType to all rtt-related
utilities.
- Remove infrastructure for abstract-type rtts from the wasm compilers,
setup-heap-internal.cc, roots.h, and module-instantiate.cc.
- Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
from ref.test, ref.cast and br_on_cast implementations in the wasm
compilers.
- Remove unused 'parent' field from WasmTypeInfo.
- Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
and CreateArrayMap.
- Use more convenient arguments in IsHeapSubtypeOf.
- Update tests.
Bug: v8:7748
Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72321}
This reverts commit ec7e9a8dbc.
Reason for revert: failure was due to a clang bug that is fixed in
latest rolled clang.
Original change's description:
> [test] Disable cctest/test-loop-analysis/LaEdgeMatrix2_0 on ODROID
>
> Bug: chromium:1163847
> Change-Id: Iabb152cd1a5c04e2032cb1254d8b27ea081cbb27
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614427
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71952}
TBR=machenbach@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1163847
Change-Id: Iba18918e8ceab166e7d5e9751e857f13142ed583
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2647153
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72310}
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 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 5a0938e593.
Reason for revert: Broke build https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8857098178780038608/+/steps/Check/0/logs/RunWasm_I32x4WidenI8x16S_liftoff/0
Original change's description:
> [wasm-simd][x64] Prototype i32x4.widen_i8x16_{s,u}
>
> This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
> uses some masks and pshufb for the widening. These masks (3 for each
> instruction) are stored as external references.
>
> Bug: v8:11297
> Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72301}
TBR=neis@chromium.org,gdeepti@chromium.org,neis@google.com,ahaas@chromium.org,zhin@chromium.org
Change-Id: I83aa2e86854e39ac6afd250fdc0dfac7cdd99e6d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11297
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2648194
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72302}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
uses some masks and pshufb for the widening. These masks (3 for each
instruction) are stored as external references.
Bug: v8:11297
Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72301}
Factor out the code sequence into macro-assembler functions to be reused
by Liftoff.
Bug: v8:10975
Change-Id: I82e253c94e09bf62197e7de87359d0e3956d2dcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643662
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72300}
The change https://chromium-review.googlesource.com/c/v8/v8/+/2572173
implemented HostGetSupportedImportAssertions [1] in a fairly literal
sense, where the host supplies a list of supported import assertions
and V8 filters the import assertions in a ModuleRequest and exposes
only supported assertions via its API surface.
However, we've decided that the interop guarantees provided
by doing the filtering in V8 are probably not worth the added
complexity. Thus, this change removes the filtering. Going forward,
hosts will be expected to ignore unknown asserions received from V8.
This is mostly a revert of
https://chromium-review.googlesource.com/c/v8/v8/+/2572173, with
v8::Isolate::CreateParams::supported_import_assertions being kept
for now (since we first have to delete the Blink code that sets it),
and a new comment in v8.h instructing hosts to ignore unknown
assertions.
[1] https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions
Bug: v8:10958
Change-Id: I7e8e2a7fbfe2d5bf891805cff6c3160d0e6825cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643563
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72299}
Prototype these 6 instructions on x64:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
Some of these code sequences make use of special masks, we keep them in
external references.
Code sequence based on suggestions at:
https://github.com/WebAssembly/simd/pull/383
Bug: v8:11265
Change-Id: Ied67d7b5b6beaaccac7c179ec13504482cb9c915
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643562
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@{#72297}
According to the latest wasm-gc spec, the type immediate for the
argument's heap type is no longer required. This CL also adds a missing
check that the rtt immediate is a subtype of the argument's type.
Bug: v8:7742
Change-Id: I627002d1c4bdb4ca3f2181d2f4b659ce3e95cb2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642246
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72287}
- Use movl which clears the upper 32bits on x64
- Use xorl + movb for Smi.ptr values <= 0xFF, saving one byte over movl
Change-Id: Iacdacfbe397670667e71d1d12ef427a01994481d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642250
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72282}
This implements support for the following instructions:
ref.func, call_ref, return_call_ref
Bug: v8:7748,v8:9495
Change-Id: If5bdc2b9bc2347de056de2917430b8d9dc901c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632591
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72270}
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}
This ensures that large objects have alignment suitable for a fixed
double arrays.
Bug: chromium:1161759
Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72251}
This fixes typing (and type conversions) in the two compilers and adds a
test for executing a memory.size instruction in memory64.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ic06b224437cb818ad74d0732fc4c8e08c9095231
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632594
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72219}
The icache and jump-table-assembler tests need memory that is both
writable and executable. On Mac, to do this we need to pass MAP_JIT to
mmap which is wired with the VirtualMemory::JitPermission flag.
Change-Id: If8236fa8983a4a59ef39fe777f26a02103dc6f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637227
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#72217}
DevTools can't unambiguously determine whether code is JS or wasm.
This CL adds a string to the tracing output that will be 'JS', 'wasm' or
'other'.
Bug: chromium:1168052
Change-Id: Iaacb5ea9a83327e22d60bf6114f607e6fa5532ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637859
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72193}
This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.
This change is mechanical:
git grep -l BailoutId | while read f; do \
sed -i 's/BailoutId/BytecodeOffset/g' $f; done
With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.
Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
Doing a function call into the logger to decide whether logging is
enabled or not is more costly than necessary.
This CL changes logging to take FLAG_log as main signal whether logging
could be active. If FLAG_log == false, logging cannot be active. In
that case we always call into the logger and perform detailed checks
there.
This CL changes flag-definitions to set FLAG_log if they need logging.
Change-Id: Ia51ed9fb7128451bf1dcf345fab257547aab4a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602461
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72186}
This would be useful for ForInPrepare. Syntax is unchanged; Torque
should now do the right thing for builtins that return a two-element
struct. More elements than that is still not supported.
Bug: v8:7793
Change-Id: Ic315699402203aba07e906ff6e029834ec0061c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596498
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72171}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for the
interpreter.
This is the first instruction of its kind, a post-mvp, unary operation
that takes one immediate. Which is why there are more changes to the
decoder than usual.
Bug: v8:11297
Change-Id: Ib5c58965e0cba8d7a395b0dc57673110bc60e87c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617385
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72170}
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}
On arm64, Windows Performance Recorder gets confused by the fact that fp
in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
caller frame. The expected usage of fp is documented in [1]:
The frame pointer (x29) is required for compatibility with fast stack
walking used by ETW and other services. It must point to the previous
{x29, x30} pair on the stack.
In slightly more detail, the Windows function RtlWalkFrameChain is
responsible for generating stack traces during profiling with Windows
Performance Recorder, and that function relies on the rule quoted above.
Notably, it does not make any effort to read the unwinding data that one
could obtain with RtlLookupFunctionEntry. Stack walks using that data,
such as those performed by WinDbg and the cctest StackUnwindingWin64,
work fine.
It would be convenient if we could use fp in a more standard way during
JSEntry so that Windows profiling tools work correctly. (We can also
reduce JSEntry by two instructions in doing so.)
Both arm and arm64 currently put a -1 value on the stack at the location
that fp points to. This could prevent accidental access during the
epilog of JSEntry, where fp might be zero. However, we believe that this
protection is no longer necessary, and any bug that causes a read from
fp during the end of JSEntry would cause various CQ failures.
[1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72165}
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI
Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.
Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).
Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}
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}
For asynchronous compilation, the beginning and end of compilation are
marked with different trace events. To allow to connect these events, a
compilation id is added to the start and end events. Note that the
compilation id is not added to all trace events to avoid bloating
traces. Ids may be added later to these events if necessary.
R=clemensb@chromium.org
Bug: chromium:1084929
Change-Id: I36ad598d27dea355fcca8992534c91e5a880fdaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629274
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72144}
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}
For memory64, the init expressions for data segments provide a 64-bit
value. This CL adds a new {EvalUint64InitExpr} function alongside
{EvalUint32InitExpr}. It supports i64.const and global.get operations.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I58acbb28acb8771a0947f9d5df1c14e6ca0f79cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632589
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72131}
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}
This reverts commit b3d09001eb.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that
Original change's description:
> [objects] Remove uncached internal external string type
>
> We shouldn't be creating those anymore since they are not thread-safe.
>
> Bug: v8:7790
> Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72006}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72122}
This reverts commit 37c3e05e81.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that
Original change's description:
> [test] Update MakeExternal tests
>
> They weren't initializing the VM at the start of the test. Also updated
> the test description.
>
> Bug: v8:7790
> Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71978}
TBR=leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I35bc0090c3beed4ef11a458f0e26c44b22f7b654
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627606
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72114}
76217f5 fixed the profiler so it would only sample a thread if
it had the Isolate lock. Unfortunately, this fix missed a timing
window where a thread might have the Isolate lock but might not
have restored the thread-specific data such as thread_local_top_
for the locked thread yet, so the sampler might end up using data
from a different thread.
This doesn't cause any seg faults or the like because the thread
we *meant* to sample has the Isolate lock so the thread we're
accidentally sampling can't mess with any Isolate data but we can
still get incorrect sample data which can be especially obvious if
the accidentally sampled thread is inside code that would never
run on the thread we meant to sample.
Fortunately, we can tell when all thread-specific data has been
restored to the Isolate because thread_state_ in the
PerIsolateThreadData for a thread is set to a non-null value
until everything has been restored, at which point it gets set
to null. So the fix adds a check after the test for the Isolate
lock to check if thread_state_ is null for the thread we mean to
sample. If so, we know all the data in the Isolate is good to go
for sampling.
Bug: v8:11316
Change-Id: I02d6361d8cbd6ec809ad8fb7ef07f5e9c94c7d1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628133
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72112}
Port: 646bdbf843
Bug: v8:10972
Change-Id: I9b199dc75d0e759a768da55298af383ebeb30e90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632351
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72108}
Remove the ambient dependency on the currently entered isolate, let the
embedder pass it in explicitly.
Bug: v8:11287
Change-Id: I03690390a308a59e2c6ea5c6ae268780d836b717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608209
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72105}
Implement these 4 instructions for arm64 and arm Liftoff:
- i64x2.widen_low_i32x4_s
- i64x2.widen_high_i32x4_s
- i64x2.widen_low_i32x4_u
- i64x2.widen_high_i32x4_u
Drive-by cleanup of the test case to make it clearer that we are
checking against an unsigned result.
Bug: v8:10972
Change-Id: I509a8df8a6f2109417ad5aaaa0324ced50bdc84a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626713
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72074}
bulk-memory shipped in V8 v7.5, hence the feature flag can be removed
now. This saves some binary size and a few dynamic checks for the flag.
R=ahaas@chromium.org
Bug: v8:11074
Change-Id: Ia73622637939f2192940fdd6909520786ed27286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622913
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72045}
`0x12345678` will be written to memory in the same order on BE
machines however, as Wasm is LE enforced, a memory load will
force a byte reverse operation on BE machines which changes the value.
To fix the problem, we write the reversed value to memory.
Change-Id: I0d562768d5cef823cb918ed1b57a2a41e404ffc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622927
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72041}
... and fix an issue in TurboFan and issues in Liftoff.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I3493205ab56a4ded550af6fcd75c465f7d8894ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618246
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72035}
Prototype these 4 instructions:
- i64x2.widen_low_i32x4_s
- i64x2.widen_high_i32x4_s
- i64x2.widen_low_i32x4_u
- i64x2.widen_high_i32x4_u
Implementation is the same as x64.
Drive-by fix to add a missing CpuFeatureScope to x64.
Bug: v8:10972
Change-Id: Iacc84bce156053d0ac39b1a419727c93c499a8c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612339
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72025}
Also remove some ifdefs since it is implemented on all architectures.
Bug: v8:10997
Change-Id: I06f82e2c67219a8990bdd7c78e63b1300c8f34d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620907
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72024}
Implementation is the same as x64.
Disassembly support for the new instruction, pmulhrsw, is already
supported due to the macro list.
Bug: v8:10971
Change-Id: I099c4f8c3da521006ef5e2b151626f25a5df1ed9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620898
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72021}
In memory64, the index is a 64-bit value even on 32 bit. Thus the bounds
check needs to check explicitly that the high word is zero. The (pointer
sized) low word is then checked against the actual memory size.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I311664ccadaec44a6c88777a60b1a3b45b6c0642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617088
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72016}
This adds a first execution test for memory64 in the form of a cctest.
Several things are still not working correctly, hence this test only
checks TurboFan on 64-bit systems, and Liftoff.
Bounds checks in Liftoff are fixed to work correctly on 32-bit.
Follow-up CLs will extend the test to also test TurboFan on 32-bit, the
interpreter, and traps. All of those features still have issues.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ic7edcf3783421634fe2ec99eac6f257c557a29b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610968
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72014}
We shouldn't be creating those anymore since they are not thread-safe.
Bug: v8:7790
Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72006}
Invoking Goto in graph-builder-interface from inside a 'let' can cause
the number of locals between source and target ssa environment to be
different. This CL addresses this bug and adds a few unit tests.
Unfortunately, after this change we have to resort to always using
copy-constructors for SsaEnv, which might cause slowdown in decoding.
Bug: v8:9495
Change-Id: Idf5ace6c7563eff9d774d402f3a81e77959556ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614062
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71993}
This is a reland of a3ce2f6da2
(No changes; was reverted because a dependency was reverted.)
Original change's description:
> [wasm-gc] Liftoff support part 5: i31
>
> This implements support for i31.get_s and i31.get_u.
>
> Bug: v8:7748
> Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71808}
Bug: v8:7748
Change-Id: Id8e66cab285d2a36fcd712b92a522e83dea93193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71984}
Prototype load lane instructions on Liftoff, only for x64.
Bug: v8:10975
Change-Id: Ifdf58f08b65762d592e99de91c7c622d2a964a9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612335
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71980}
They weren't initializing the VM at the start of the test. Also updated
the test description.
Bug: v8:7790
Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71978}
In order to avoid internal external uncached Strings, we can copy the
String at the moment of internalizing if it is an external & uncached
String.
Bug: v8:7790
Change-Id: Ie7ed287c105a127b8b4c867aab1a808265a922b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613029
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71977}
This is a reland of 94f2212b4d
Nothing changed, think the failures were flaky.
Original change's description:
> [wasm-simd] Scalar lowering for extended multiply
>
> R=bbudge@chromium.org
>
> Bug: v8:11262
> Change-Id: Idd6a7514a16c561832af603dbf63779a0e402f45
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603771
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71920}
Bug: v8:11262
Change-Id: I6c504b2e0d1ad39e202483a72419dadb3b66eea8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612330
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71965}
When AVX2 is available, we can use vbroadcastss. On AVX, use vshufps,
since it is non-destructive. On SSE, shufps is 1 byte shorter.
FIXED=b/175364402
Change-Id: I5bd10914579d8db012192a9c04f7b0038ec1c812
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599849
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71964}
There's a bit more work to do to add support for import assertions for
dynamic import(). This is the first of a series of changes to do that.
This adds parser support for the form of import() that takes import
assertions per https://tc39.es/proposal-import-assertions/#prod-ImportCall
A future change will pass the assertions expression along to
Runtime_DynamicImportCall where the assertions will be unpacked and
filtered per Isolate::supported_import_assertions_.
Bug: v8:10958
Change-Id: Ib1c80d15ac44923d97c5fdfcc4bd732cb9245cf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612038
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71960}
When --harmony-dynamic-import was removed in
https://chromium-review.googlesource.com/c/v8/v8/+/2509942 it looks
like we were left with some redundant invocations of
RunParserSyncTest/RunModuleParserSyncTest in ImportExpressionErrors.
This removes them.
Change-Id: I2fb68c7e21bc4e039ab77396cdca7ca0d18eca95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613370
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71956}
This fix the following instructions:
kExprI32SConvertF64 in mips32, RecordSpillsInSafepoint in mips32 and mips64.
Change-Id: I762fe4a7afa06fa8470fb0de932756a145d66099
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605905
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71889}
In AVX, it is better to use the appropriate integer or floating point
moves depending on which instructions produce/consume these moves, since
there can be a delay moving from integer to floating point domain. On
SSE systems, it is less important, and we can move movaps/movups which
is 1 byte shorter than movdqa/movdqu.
This patch cleans up a couple of places, and defines macro-assembler
functions Movdqa, Movdqu, Movapd, to call into movaps/movups when AVX is
not supported.
Change-Id: Iba6c54e218875f1a70f61792978d7b3f69edfb4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599843
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71884}
With https://crrev.com/c/2087396 we introduced a new CDP method
`Debugger.executeWasmEvaluator()`, which we originally intended
to use as the foundation for Debug-Evaluate on Wasm frames.
However in the process of prototyping we learned that it is too
costly and too inefficient to use WebAssembly modules here, and
we switched to regular Debug-Evaluate with JavaScript instead
(with a special debug proxy exposed that allows JavaScript to
peak into the Wasm frame), since JavaScript is better suited
for short-lived / short-running snippets and we don't need
clang and wasm-ld then to generate these snippets.
The JavaScript exposed debug proxy (as described in [1]) not
only enables more powerful and flexible Debug-Evaluate for the
DWARF C/C++ extension, but also serves as the basis for various
aspects of the Basic Wasm Developer Experience.
In order to pay down technical debt and to keep the maintenance
overhead low, we should remove the initial prototype now, also
to ensure that we don't accidentally attract other users of CDP
to rely on this unsupported API (despite it being marked as
"experimental").
[1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
Fixed: chromium:1162062
Bug: chromium:1020120, chromium:1068571, chromium:1127914
Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71882}
Detect AVX2 support and use vpbroadcastb or vpbroadcastw.
No new assembler helpers required because we are only emitting the
VEX-128 versions of these instructions.
Bug: v8:11258
Change-Id: Ic50178daa6fc8fe767dfc788e61e67538066bdea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596582
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71866}
When a 8x16 shuffle matches a 32x4 shuffle (every group of 4 indices are
consecutive), and the first 2 indices are in the range [0-3], and the
other 2 indices are in the range [4-7], then we can match it to a
shufps. E.g. [0,2,4,6], [1,3,5,7]. These shuffles are commonly used to
extract odd/even floats.
Change-Id: I031fe44f71a13bbc72115c22b02a5eaaf29d3794
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596579
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71860}
As a first step towards freeing CodeEntry objects that are neither still
referenced by JS or stored in a profile, enable freeing of refcounted
strings by CodeEntry instances. For now, this leaves behaviour unchanged
until we receive CodeEntry destruction events.
Bug: v8:11054
Change-Id: Iabd05aa730343cd1a879ff5b04326f23e68aa948
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590604
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71858}
Port: 4ad68f1c83
Bug: v8:11008
Change-Id: I0aa384612b529babf9e526fca83c8c69f58b6f3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2592828
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#71847}
The opcodes were renamed long ago, but the macros were still using the
old syntax.
This CL was created using the following script (for WASM_GET_GLOBAL and
WASM_SET_GLOBAL):
ag -l WASM_GET_GLOBAL | xargs -L 1 sed -i 's/\bWASM_GET_GLOBAL\b/WASM_GLOBAL_GET/g'
R=ahaas@chromium.org
Bug: v8:11074
Change-Id: I3a9bd64f6e09ce97dae6d4132c224350dc079c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2597576
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71836}
The opcodes were renamed long ago, but the macros were still using the
old syntax.
This CL was created using the following command (for WASM_GET_LOCAL,
WASM_SET_LOCAL, and WASM_TEE_LOCAL):
ag -l WASM_GET_LOCAL | xargs -L 1 sed -i 's/\bWASM_SET_LOCAL\b/WASM_LOCAL_SET/g'
R=ahaas@chromium.org
Bug: v8:11074
Change-Id: I0018bea185030be29344e66e59706fed183cc2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595446
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71835}
This CL changes SharedFunctionInfo::GetBytecodeArray to a function
template, which is specialized for Isolate and LocalIsolate arguments.
This allows main thread only uses to avoid taking a lock.
Bug: v8:7790, chromium:1154603
Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71833}
When we know a value passed to BytecodeArrayBuilder::LoadLiteral(double)
can be encoded as a Smi, we create LdaSmi instead of LdaConstant.
Driven by a forgotten Smi::FromInt() in BytecodeGenerator, also fixed in
this CL.
Bug: v8:11278
Change-Id: I4a1ad48e2c9aff8391113812e34dae838a1a38d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595437
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71827}
This reverts commit 860fcb1bd2.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
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}
TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11092
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71825}
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}
This is a reland of dc369749c7
Changes: relaxed --liftoff-only mode to still allow bailing
out due to missing CPU support.
Original change's description:
> [wasm-gc] Liftoff support part 4: subtyping
>
> This adds support for the following instructions:
> struct.new_default, rtt.sub, ref.test, ref.cast
>
> Bug: v8:7748
> Change-Id: I7423ddd7a83c80cb1e82c620780c27bec59ec762
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593341
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71805}
Bug: v8:7748
Change-Id: If31fcee5e7e173d7c2a6e1c624f4ff04cec7fe9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596338
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71823}
These instructions have been accepted into the proposal.
Bug: v8:11262
Change-Id: Iec0bb9b9b1b0f8ed76ed78e254c64b96981a5f2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589433
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71819}
We can have more optimizations for this instruction, they leave some
junk in the top lanes of dst, but that doesn't matter:
- when lane is 1: we use movshdup, this is 4 bytes long
- when lane is 2: use movhlps, this is 3 bytes long
- otherwise use shufps (4 bytes) or pshufd (5 bytes)
All of which are better than insertps (6 bytes).
Change-Id: I0e524431d1832e297e8c8bb418d42382d93fa691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2591850
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71813}
This implements support for i31.get_s and i31.get_u.
Bug: v8:7748
Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71808}
This adds support for the following instructions:
struct.new_default, rtt.sub, ref.test, ref.cast
Bug: v8:7748
Change-Id: I7423ddd7a83c80cb1e82c620780c27bec59ec762
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593341
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71805}
Concurrent inlining is enabled for TurboProp compiles, but we don't
enable the --concurrent-inlining flag so don't also set the implied
turbo_direct_heap_access flag. This CL fixes this.
BUG=v8:9684
Change-Id: I298febdf7c466385047f420d4c33ca0162778210
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593344
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71804}
This is a reland of b2a611d815
Original change's description:
> [Turboprop] Move dynamic check maps immediate args to deopt exit.
>
> Rather than loading the immediate arguments required by the
> dynamic check maps builtin into registers in the fast-path,
> instead insert them into the instruction stream in the deopt
> exit and have the builtin load them into registers itself.
>
> BUG=v8:10582
>
> Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71790}
TBR=tebbi@chromium.org,gsathya@chromium.org
Bug: v8:10582
Change-Id: Ieda0295ee135bff983c67c3f04bb47115f0a2739
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595311
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71803}
There is a race in the way we handle deopts that made this test flaky.
The race is not hugely important to fix, and is difficult without
breaking something else.
The best thing to do here is update the test to reflect reality so we
can get the test coverage back.
This updates the test so that the deopt reason can be found either
on the first or second level function. The test assumed it would
always be available on the second level function in the profile,
but if we get a regular profile tick at the exact wrong time, we
could end up with the deopt info getting attached to the first level
function. So we accept either.
Bug: v8:5193
Change-Id: Ia43880ebafd1341a514b3143dc215514b5dccf15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594775
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71797}
This adds support for the following instructions:
ref.eq, array.new_with_rtt, array.new_default_with_rtt,
array.get, array.set, array.len.
Bug: v8:7748
Change-Id: I93c4a6676acc8b0ac035dd50762be6a1cc545a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593340
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71796}
This reverts commit b2a611d815.
Reason for revert: Several failures on https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/3743/overview
Original change's description:
> [Turboprop] Move dynamic check maps immediate args to deopt exit.
>
> Rather than loading the immediate arguments required by the
> dynamic check maps builtin into registers in the fast-path,
> instead insert them into the instruction stream in the deopt
> exit and have the builtin load them into registers itself.
>
> BUG=v8:10582
>
> Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71790}
TBR=rmcilroy@chromium.org,gsathya@chromium.org,tebbi@chromium.org
Change-Id: I4c56bee156ffcea8de0aeaff9ac1bf03e03134c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10582
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595308
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71793}
Rather than loading the immediate arguments required by the
dynamic check maps builtin into registers in the fast-path,
instead insert them into the instruction stream in the deopt
exit and have the builtin load them into registers itself.
BUG=v8:10582
Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71790}
We were storing the pointer to the WasmModule both as a shared_ptr and
as a raw pointer. Maybe this had historical reasons, but now it's just
redundant.
R=thibaudm@chromium.org
Change-Id: Id72d102b6df804f93e3ab0235eeceef91a6dd8fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593334
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71782}
This moves some fields and methods from the WasmRunner template to the
WasmRunnerBase base class. This avoids repeated compilation for the
different instantiations of the WasmRunner template.
Additional changes:
- SetUpTrapCallback, SetThreadInWasmFlag, and ClearThreadInWasmFlag are
static now.
- CheckUsedExecutionTier is unused, and did not even compile any more.
In the template class this was OK, because it's only compiled on first
use.
R=thibaudm@chromium.org
Change-Id: I485729cf4a1fd93fe6abb0be269694f0179fc4ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593331
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71781}
Implement the HostGetSupportedImportAssertions, whose purpose
is to filter the list of import assertions exposed to the embedder to
only those assertion with keys that the embedder recognizes. See
https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions.
This change doesn't actually implement it as a callback, but instead
passes the supported assertions during creation of the Isolate via
CreateParams. This expresses clearly the requirement that the supported
assertions must never change for the lifetime of the Isolate.
Note that we still need to maintain all assertions in a map
while parsing the import assertions clause, because duplicate keys for
an unsupported assertion still needs to be detected as a parse error. So,
the filtering is done later during
SourceTextModuleDescriptor::AstModuleRequest::Serialize.
The actual filtering algorithm simply iterates the assertions and the
supported assertion keys in a nested loop. There's currently only one
assertion in use ("type"), so there should be no reason to get too
clever here unless at least several more assertions are generally
supported.
Bug: v8:10958
Change-Id: I9a2d965e9d452718d0ddfe9dca55b7b4ed963019
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2572173
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71776}
This adds support for the following instructions:
br_on_null, ref.as_non_null, br_on_cast, i31.new
Bug: v8:7748
Change-Id: I210b8979327ea0031f89748b71b51abbac10bb8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590041
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71773}
NewSpace::Grow shouldn't be invoked when the maximum semi space size
was already reached.
Bug: v8:11199
Change-Id: I78ba71b7a043f0a515be188f2023e301d6bc6eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584864
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71769}
This is a reland of bee5992a6d.
Fixes a TSan race report by replacing a FlagScope in tests with
direct assignment to the flag in question.
Original change's description:
> [wasm-gc] Initial Liftoff support
>
> This CL implements Liftoff support for struct.get/set,
> struct.new_with_rtt, rtt.canon, and ref.is_null, which
> is enough to make the first testcase pass.
>
> Bug: v8:7748
> Change-Id: Id09e9872d2126127192c852b3cb6d57ff9417582
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584951
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71744}
Bug: v8:7748
Change-Id: I17de6803c23a88209102385010dfdf9b88e25ace
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593254
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71762}
Since the compile job can always be reused after creation (even if it
runs out of work), we do not need the logic to (re-)initialize it. In
fact, it will always only be initialized once already.
This allows us to initialize it once during construction of the
compilation state (or right after the initialization), and then access
it without locks later.
In addition, this CL
1) renames "current_compile_job_" to "compile_job_", since there will
always only be one now;
2) removes the {ScheduleCompileJobForNewUnits} method, and just does a
{compile_job_->NotifyConcurrencyIncrease()} instead;
3) removes the {has_priority_} field and just directly does a
{compile_job_->UpdatePriority} call.
The streaming test platform needed to be fixed to avoid calling {Join}
on the job handle, which would invalidate the handle afterwards.
Instead, we just run all tasks as long as there are any.
R=thibaudm@chromium.orgCC=etiennep@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I7094231e86d5f54cfca5e971b96fd81e994c874a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584946
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71757}
Codegen is identical to x64.
Tweaked a macro definition to do a dst == src1 check when AVX is not
supported, and updated a single caller in LiftOff.
Bug: v8:11086
Change-Id: Ic9645f3d1bf1c26a1aa6db6bc2fa67fc991f8bbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579928
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71756}
Code like:
x = wasm_v32x4_shuffle(x, x, 1, 2, 3, 0);
is currently matched by S8x16Concat, which lowers to two instructions:
movapd xmm_dst, xmm_src
palignr xmm_dst, xmm_src, 0x4
There is a special case after a S8x16Concat is matched:.
- is_swizzle, the inputs are the same
- it is a 32x4 shuffle (offset % 4 == 0)
Which can have a better codegen:
- (dst == src) shufps dst, src, 0b00111001
- (dst != src) pshufd dst, src, 0b00111001
Add a new simd shuffle matcher which will match 32x4 rotate, and
construct the appropriate indices referring to the 32x4 elements.
pshufd for the given example. However, this matching happens after
S8x16Concat, so we get the palignr first. We could move the pattern
matching cases around, but it will lead to some cases where
where it would have matched a S8x16Concat, but now matches a
S32x4shuffle instead, leading to worse codegen.
Note: we also pattern match on 32x4Swizzle, which correctly generates
Change-Id: Ie3aca53bbc06826be2cf49632de4c24ec73d0a9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589062
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71754}
pextrq + movq crosses register files twice, which is not efficient.
Optimize this by:
- checking if lane 0, do nothing if dst == src (macro-assembler helper)
- use vmovhlps on AVX, with src as the operands to avoid false
dependency on dst
- use movhlps otherwise, this is shorter than shufpd, and faster on
older system
Change-Id: I3486d87224c048b3229c2f92359b8b8e6d5fd025
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589056
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71751}
This is the same as the original implementation in https://crrev.com/c/2567534
which was speculatively reverted due to flaky tests. Since then, there have
been some changes to fix those tests, so trying to get this in again.
Bug: v8:11002
Change-Id: I5bd0f63d3aec4cf6db403b35737f8b695b0f4e37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589063
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71746}
This CL implements Liftoff support for struct.get/set,
struct.new_with_rtt, rtt.canon, and ref.is_null, which
is enough to make the first testcase pass.
Bug: v8:7748
Change-Id: Id09e9872d2126127192c852b3cb6d57ff9417582
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584951
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71744}
The original implementation of matching was a RegExp on the source
which wasn't able to reliably distinguish between comments inside
of string literals and actual comments. For that reason, it had
a special rule to disallow quotes to remove false positives.
Original comment:
> Also, ['"] are excluded from allowed URLs to avoid matches
> against sources that invoke evals with sourceURL.
After the code was moved into the scanner, that shouldn't be an
issue anymore - the scanner knows that this is a real comment and
isn't part of a string literal.
Allowing quotes enables a slightly smaller encoding of source maps,
specifically in the case where there are no sourceContents:
Non-base64 source maps can get away with effectively no encoding
overhead (they typically don't contain whitespace).
Change-Id: Iffa5df28d80656fa56e603e7c0e57aa1f44d0014
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576801
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Jan Krems <jankrems@google.com>
Commit-Queue: Jan Krems <jankrems@google.com>
Cr-Commit-Position: refs/heads/master@{#71742}
I think this was likely fixed by one of the other bugfixes in the
meantime. It doesn't flake with 50k runs locally.
Fixed: v8:2008
Change-Id: I9e6f1e7f75cf20c52d49937d980aafacaa23b401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584945
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71715}
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Implementation is almost identical to x64, except that in the
instruction-selector, for AVX, we allow the second operand to
be a slot, and so we use InputOperand in the codegen.
Bug: v8:11008
Change-Id: I5b5ea4b5058dc0bf5ff1c24a67f9b787c5312106
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576887
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71705}
So far we reported the script ID, but DevTools ignores that and uses the
source url instead. That url was just set to "wasm ", which the frontend
couldn't make any sense of.
This CL fixes this by passing the source URL to the code create event,
and also setting the position of the code inside the script (i.e.
wasm module).
R=thibaudm@chromium.org, petermarshall@chromium.org
Bug: chromium:1125986
Change-Id: Ic41dcd2768c60fd6748468d3a89fc4ffccb35932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581543
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71695}
Add new macro-assembler instructions that can handle both AVX and SSE.
In the SSE case it checks that dst == src1. (This is different from that
the AvxHelper does, which passes dst as the first operand to AVX
instructions.)
Sorted SSSE3_INSTRUCTION_LIST by instruction code.
Header additions are added by clangd, we were already using something
from those headers via transitive includes, adding them explicitly gets
us closer to IWYU.
Codegen sequences are from https://github.com/WebAssembly/simd/pull/380
and also
https://github.com/WebAssembly/simd/pull/380#issuecomment-707440671.
Bug: v8:11086
Change-Id: I4c04f836e471ed8b00f9ff1a1b2e6348a593d4de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578797
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71688}
