This reenables a test which is passing, independent of missing
accounting for shared memory. This is because we repeatedly trigger a GC
explicitly in all workers.
R=dinfuehr@chromium.org
Bug: v8:12278
Change-Id: I73d1513d809787284af0be4956018806719acd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3201995
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77219}
Trying to optimize in such case breaks down the optimization, as we
end up with potentially non-eliminatable nodes that depend on the dead
IfTrue/IfFalse node.
Drive-by: Clean up dead nodes with {Kill()}.
Bug: v8:11510, chromium:1255354
Change-Id: Ia89fe6c243974c3c2abac6ad80bd4677a935f637
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3200073
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77211}
The checks for assignemnts to member during prefinalizers assumed the
slot has to live. It was assumed that if a slot is dead then we would
not be updating it.
Prefinalizers are allowed to touch dead objects and thus are techincally
allowed to write to dead slots. Such writes are usually redundant (the
object will be swept soon anyway) but are not always easy to get rid of.
Bug: chromium:1255152, v8:11749
Change-Id: I57e143abd53d434c3198616909c506eb70d8944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199800
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77208}
When scanning for capture groups, we have to consider the case that the
current state is inside a character class. In that case skip everything
until the end of the current character class. Otherwise we would wrongly
count open brackets inside the character class as start of a capture
group.
Bug: chromium:1254704
Change-Id: I91d2177c464f7e507413d96216fe570253f17676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199871
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77204}
If processing the marking worklists found new ephemeron pairs, but
processing the existing ephemeron pairs didn't mark new objects, marking
would stop and the newly discovered ephemeron pairs would not be
processed. This can lead to a marked key with an unmarked value.
Bug: chromium:1252878
Change-Id: I0f158f6f64490f1f06961520b4ba57fa204bd867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199872
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77197}
When we generate identical signatures in the fuzzer,
we generate one function for each of the copies.
However, when these functions are added to WasmModulBuilder,
all will be assigned the same signature index.
Therefore, when ref.func tries to find a function corresponding
to a signature index, it will fail, despite a matching signature
existing in the module.
This CL fixes this issue by looking up functions by signature
over signature index.
Bug: v8:11954, chromium:1254387
Change-Id: Iac8d5444d4914d993da63d0630ca4d95e671630c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197711
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Cr-Commit-Position: refs/heads/main@{#77187}
The logic to locate the correct function to set a breakpoint in based
on script position was treating SharedFunctionInfo::EndPosition() as
inclusive rather than exclusive. There are various assumptions all over
the Debugger that seem to demand this treatment for the toplevel script.
But it's definitely wrong for function literals.
Fixed: chromium:1253277
Change-Id: I3421703673f4d78aee28e923e03e2fca24bc06ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197715
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77186}
Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
as side-effect free (in async functions), but that's not correct, since
promise rejections have side-effects (at the very least triggering the
unhandled promise rejection machinery in the browser).
This required a minor refactoring as previously we'd classify functions
as side-effecting or not depending on whether they contain any calls to
side-effecting intrinsics, no matter whether this call is actually
executed or not. That would break REPL mode however if we'd generally
treat all async functions with %_AsyncFunctionReject intrinsic calls as
side-effecting, so instead of performing the intrinsic checks ahead of
time, we now perform the test at execution time.
Before: https://imgur.com/5BvJP9d.png
After: https://imgur.com/10FanNr.png
Fixed: chromium:1249275
Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77183}
We implement two optimizations for trap conditionals for patterns that
come up in wasm-gc.
In case of a Merge followed by a trap, where the path conditions of all
branches of the Merge contain the trap condition, we lift the trap into
the branches of the Merge.
In case of a Branch whose IfTrue branch is followed by a TrapIf with the
same condition, we replace it with the trap followed by the IfFalse
branch. Symmetrically for IfFalse and TrapUnless.
Bug: v8:7748
Change-Id: I43040aebe60eab7b2230fc3130e3b8250e8b2f45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190109
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77181}
Currently, it is possible to declare macros, builtins, etc., without
specifying a return type, in which case the return type is treated as
void. This is confusing; the code is more clear if we require the return
type to be specified.
Aside from src/torque, this change is almost entirely just adding
`: void` until the compiler is happy. However, two intrinsics in
src/builtins/torque-internal.tq have been corrected to declare an
appropriate return type. Those two intrinsics were only used in code
generated within the compiler after the type-checking phase, so we never
noticed that their return types were declared incorrectly.
Bug: v8:7793
Change-Id: Ib7df88678c25393a9e3eba389a6a1c4d9233dcbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3176502
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77178}
Loop exits are only used during loop unrolling and are then removed, as
they cannot be handled by later optimization stages. Since unrolling
comes before inlining in the compilation pipeline, we should not emit
loop exits in inlined functions.
Bug: v8:12166
Change-Id: I28b3ebaf67c9e15b127eeb1a63906c4ecfd77480
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3195871
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77175}
We currently could produce the error message 'not enough arguments on
the stack for block, expected 0 more'. This CL fixes this by printing
the available number of arguments and the needed number, and adds
DCHECKs to catch similar miscomputations in the future.
It also adds a new test that produced the broken error before, and
includes the expected failure message in a few more tests for
robustness.
R=manoskouk@chromium.org
Change-Id: Ia08863889ae36ae0a05d96d36e92295b7159a01e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194264
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77167}
The test allocates a lot of wasm memories. This got a low slower after
https://crrev.com/c/3190476, because we can now allocate more than 102
memories, and do not explicitly trigger a GC any more to get rid of
unused memories.
We should figure out how to tell the GC about the external memory such
that the memories get collected earlier.
R=ahaas@chromium.org
Bug: v8:12076, v8:12278
Change-Id: I9b8795a9999a806380d86f22e751de2727942648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3196131
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77164}
The address space limit puts an arbitrary cap on the total reservation
size, thus limiting the total number of Wasm memories to around 100 on
64-bit systems.
Since the usable address space on 64 bit is much larger than the
1TB+4GB limit, this makes us reject code that we could otherwise just
execute.
This CL thus removes that limit completely.
See the linked issue for more discussion, including security
considerations.
R=jkummerow@chromium.org, rsesek@chromium.org
Bug: v8:12076
Change-Id: I1f61511d68efdab1f8cef4e09c0a39fc1d6fed60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190476
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77161}
It's confusing that we have CSA_CHECK and CSA_ASSERT and it's not
clear from the names that the former works in release mode and the
latter only in debug mode.
Renaming CSA_ASSERT to CSA_DCHECK makes it clear what it does. So now
we have CSA_CHECK and CSA_DCHECK and they're not confusing.
This also renames assert() in Torque to dcheck().
Bug: v8:12244
Change-Id: I6f25d431ebc6eec7ebe326b6b8ad3a0ac5e9a108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190104
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77160}
The V8 Inspector was sending an additional frame as part of async stack
traces for async functions, which pointed to the first executed `await`
in the async function. This is leaking an implementation detail of how
(and more precisely when) the inspector decides to collect this stack
trace. From the users perspective the async part of the stack trace is
supposed to capture what happened _prior to the task_ - meaning in case
of async functions: What lead to the execution of the async function.
This is reflected by the fact that the DevTools front-end (and the V8
Inspector itself) performs post-processing on these async call stacks,
removing the misleading top frame from it. But this post-processing is
not applied consistently to all async stack traces (i.e. the Console
message stack traces don't get this), and potentially also not applied
consistently across consumers of the Chromium debugger backend.
Instead the V8 Inspector now removes the top frame itself and thus
reports `await` consistently with how other async tasks are reported to
debugger front-ends.
Note: This preserves backwards compatibility with old versions of
devtools-frontend, which do post-processing (for the Call Stack) only on
async stack traces marked with "async function", while we now mark these
async stack traces with "await" instead (aligned with what the front-end
is using as user visibile string anyways in the Call Stack section, and
this matching will be updated in a separate follow up CL to look for
"await" instead of "async function").
Before: https://imgur.com/kIrWcIc.png
After: https://imgur.com/HvZGqiP
Fixed: chromium:1254259
Bug: chromium:1229662
Change-Id: I57ce051a28892177b6b96221f083ae957f967e52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77157}
Due to MIPS64 ISA feature, 32-bit values should be sign-extended
in 64-bit registers, no matter it's signed or unsigned.
Besides, LoongArch64 also has this feature, and a similar change
has been made before loong64 port's land in V8. This CL also make
a small fix for loong64.
Change-Id: Ib284662931082365f727925af61781e3653debc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193595
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#77154}
This fixes a long-standing TODO to disallow importing receivers that
have "toString" or "valueOf" patched. Calling those methods could have
observable side effects, so allowing that would require bigger
refactorings to ensure that we only call each such function exactly once
per import, and in the right order.
Since this use case is rare, we just forbid importing such receivers.
R=jkummerow@chromium.org
Bug: chromium:1248677
Change-Id: I99bbd7db950ec3c7ac9cc1f59e8c476688e7d7b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190475
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77149}
.. and refactor js-regexp.h.
- Hide the generic DataAt/SetDataAt accessors and replace them by
dedicated accessors. Use the common lower_case naming scheme for
these.
- Shuffle around definitions in js-regexp.h s.t. they are in a
meaningful order.
- Dedupe the source/flags accessors - these fields are stored both
on the instance and on the data array. We keep only accessors for
the instance. Previously, these were disambiguated through naming
oddities (e.g. Pattern() returned data->source).
Change-Id: I3d53c8b095f0d59621ff779608438f7fa5e8c92a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193534
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77138}
This is a reland of 7d849870ff
Original change's description:
> [regexp] Reorganize and deduplicate in the regexp parser
>
> The parser is organized in a somewhat tricky way s.t. it can be
> hard to map the implementation back to the specified grammar.
>
> In particular, the logic for CharacterClassEscape, ClassEscape,
> and CharacterEscape was implemented twice - once inside a character
> class, once outside.
>
> This CL refactors related logic to have only a single implementation.
>
> As a drive-by, fix one related inconsistency related to \k inside
> a character class.
>
> Fixed: v8:10602
> Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77114}
Fixed: v8:10602,chromium:1253976
Change-Id: I9e7cc6a34d3be06e1a68895775aa50b0eee78c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193531
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77135}
Because there can be fewer function signatures than there are
functions a new ForceAddSignature function was added which does
not deduplicate.
Bug: v8:11954
Change-Id: Ib028de47962dd1e797ead1b1f05a4e6815029487
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186431
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77126}
This reverts commit 7d849870ff.
Reason for revert: Will block roll. Broke error message tests upstream:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Win/6635/overview
Original change's description:
> [regexp] Reorganize and deduplicate in the regexp parser
>
> The parser is organized in a somewhat tricky way s.t. it can be
> hard to map the implementation back to the specified grammar.
>
> In particular, the logic for CharacterClassEscape, ClassEscape,
> and CharacterEscape was implemented twice - once inside a character
> class, once outside.
>
> This CL refactors related logic to have only a single implementation.
>
> As a drive-by, fix one related inconsistency related to \k inside
> a character class.
>
> Fixed: v8:10602
> Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77114}
Change-Id: Ic7404d6c9f0e6ea51e8cd8f1ab672856dca0c637
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190692
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/main@{#77125}
When handling the 'end' opcode, there was a confusion with the value of
"unreachable". This DCHECK assumes the value of "unreachable" before
closing the scope, but was placed after the value is potentially updated
to reflect the state after the 'end' opcode.
R=clemensb@chromium.org
Bug: chromium:1251845
Change-Id: Iea526e6485fa705f6ff4077f54a53204cc70a926
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190102
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77116}
The parser is organized in a somewhat tricky way s.t. it can be
hard to map the implementation back to the specified grammar.
In particular, the logic for CharacterClassEscape, ClassEscape,
and CharacterEscape was implemented twice - once inside a character
class, once outside.
This CL refactors related logic to have only a single implementation.
As a drive-by, fix one related inconsistency related to \k inside
a character class.
Fixed: v8:10602
Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77114}
The intent of the RISC-V ISA is that 32-bit C values are stored sign extended in registers, even for unsigned types.
So we skip cctest case RunLoadStoreZeroExtend64/RunUnalignedLoadStoreZeroExtend64 due to sign extend uint32
Change-Id: Icfe727916b1c04aad5681902ec4782cc98906964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3184560
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77112}
Several of the cctest/test-bytecode-generator/* tests used to rely
on the __COUNTER__ C++ compiler macro, which could cause spurious
test failures due to mismatched expectations when usages of that
macro were added or removed elsewhere in the code. This patch switches
to a custom, controllable static counter variable instead, to make
the tests' behaviors self-contained.
Bug: v8:12244
Change-Id: I4d875b6095e4ee4ef91933ab8c60c89054d1894a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186836
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77111}
These tests test allocation failure and time out on TSAN.
Bug: v8:11852
Change-Id: I81e0af3ab8130c05488c6a117dd1c6ef12aba33b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188071
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77104}
After the parameter processing, the arraybuffer may have been detached.
TypedArray copyWithin/fill should throw in that condition. TypedArray
includes should return false if the search element is not undefined.
Change-Id: If507d0efa1dafbe3dcefcd368e5ea27406bb3df8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144315
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77103}
Prepare the Torque compiler to generate Kythe artifacts to be consumed
by CodeSearch.
Drive-by changes.
* Extend SourcePosition by an offset in the input string, as this is
required by the Kythe graph.
* Correctly set missing identifier positions in Declarations.
Bug: v8:12261
Change-Id: Ida0a4a562c99f58ab924ddde36f3146f3d3fd415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3181102
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77099}
Don't really have a good name for this inner TryCatch.
Bug: v8:12244
Change-Id: I4c1353bcd98e78e49d0354e285249302a8ee0dd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3183522
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77097}
When cloning objects using spread and update properties (e.g.
obj = {...o, x: 0}), we wrongly used the setter for the update argument
if one was set.
This CL changes the behaviour such that all arguments following the
spread are treated as dynamic arguments.
Bug: chromium:1251366
Change-Id: I76a6d02606dca0faa0a256f465834d85d3df4f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178969
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77079}
Drive-by clean-up to move ADD_CODE, which is defined the same way in
multiple files, into wasm-run-utils.h.
R=adamk@chromium.org
Bug: v8:12244
Change-Id: I61d54cf2c589c3f8b69950fba097d8754bb99c5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3183524
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77065}
Some macros are redundant or unused.
- WASM_RETURN1 is identical to WASM_RETURN.
- WASM_RETURNN has an unused {count} parameter, and is otherwise
identical to WASM_RETURN.
- WASM_IFB is identical to WASM_IF.
- WASM_CASE and WASM_CASE_BR are unused.
- WASM_BR_TABLEV is unused.
R=thibaudm@chromium.org
Bug: v8:12244
Change-Id: Ie7be00351f2dfe38d6e84d80e157a85df37233a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178860
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77056}
Rename the enum value to avoid variable shadowing.
R=clemensb@chromium.org
Bug: v8:12244
Change-Id: I96a3bee7615b44692bb9edfedf82c6020a803d0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3181529
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77050}
NameSectionKindCode::kFunction got shadowed by
WasmCompilationResult::Kind::kFunction. NameSectionKindCode is not used
often, so this CL just adds "Code" to all fields of this enum.
R=clemensb@chromium.org
Bug: v8:12244
Change-Id: I87155a43084b868f6c118ddc2e44cb9c35b4249b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3181535
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77049}
In Liftoff, the result of table.grow was smi-untagged and sign-extended
to a ptr-sized value. However the result is typed as i32, so the upper
32 bits should be cleared on 64 bit platforms. In particular this is
observable when the value is used as an index for a memory operand,
which leads to the repro in the attached issue.
Match the TF behavior by untagging the value as a 32-bit int.
R=clemensb@chromium.orgCC=ahaas@chromium.org
Bug: chromium:1251465
Change-Id: Ia57fd8a69ecb2787b42bbf8217e448976aa1dbd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173680
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77044}
Because these instructions can trap, we don't want them to be reordered
as freely as unprotected accesses.
As part of this, make explicit which opcodes support a MemoryAccessMode.
Bug: v8:12018
Change-Id: I9db3053d7d62ffce6d3c95d62adce71ae40dae62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172770
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77031}
The tests won't be very interesting, but we should still have basic
smoke tests.
Bug: v8:11111
Change-Id: I57eadfc090883bc9b84e5b2fb5984b5ed588a69b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3177223
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77029}
Bug: v8:12244
Change-Id: I5a85e109316b349545d2699a59200c167d261842
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3180244
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77026}
Change-Id: Iba7d3f528262b3979d3bfe83784c3cfe050cd6e6
No-Try: true
No-Presubmit: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3180241
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77025}
- create a helper class to set up Disassembler for testing
- add a helper macro to only compare disassembled instruction (ignore
the hex bytes), this is useful for comparing SSE instructions, whose
opcodes are defined in sse-instr.h, and use uppercase letters, but the
disassembly always uses lowercase
- emit and compare SSE instructions using macro list
Bug: v8:12207
Change-Id: I3580f5d756736cada4f7260efc4d90e2c894f43c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173906
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77021}
'#x in expr' currently parses incorrectly and associates #x as an
operand of an existing binary expression continuation if the previous
operator was of higher precedence. For example, 0 << #x in foo gets
incorrectly parsed as (0 << #x) in foo.
Bug: v8:12259, v8:12086
Change-Id: Ie37ff49ff6e63b3ea91fd0fba6bc73ec839c580b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3176506
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77020}
The proposal has changed and we'll start on the new implementation
from scratch.
Bug: v8:11935, v8:7467
Change-Id: I29e39a414027d80fd91764ce02a05d7c032a41f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178964
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77016}
.. by reusing the regexp stack from potentially multiple nested
irregexp activations.
To do this, we now maintain a stack pointer in RegExpStack. This stack
pointer is synchronized at all boundaries between generated irregexp
code and the outside world, i.e. when entering or returning from
irregexp code, and when calling into C functions such as GrowStack.
Fixed: v8:11382
Change-Id: I5ed27630c1a64ebf3afb9ddf80fb60ea067c0c40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162604
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77013}
Generate arbitrary struct and array types based on
the fuzzer random input stream.
They replace the hard-coded types.
Generated types include nested reference types and recursive types.
Bug: v8:11954
Change-Id: I2e40697f2ace3eb818360213e8a4dd40037e580e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173683
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77010}
i32 comparisons often compare against constants, in order to implement
conditional branches. This CL optimizes such code by not loading the
constant into a register first, but directly emitting the comparison.
The code is shared for implementing {if} and {br_if} (and thereby makes
those two methods more readable).
R=thibaudm@chromium.org
Change-Id: I3f2f071a1c9e4b02c7368a2757bf4aae2920bd69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172765
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77008}
This fast path check protects the IsRegExp() path (which checks
RegExp.prototype[Symbol.match]) and thus we must use the appropriate
ForMatch check instead of the default check.
Fixed: chromium:1238033
Change-Id: I0b7ce280f1fa9bfacf20381d80c84f9513f45163
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3177222
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77004}
Liftoff is fully supported on all officially supported platforms, thus
remove a TODO to implement it on more platforms.
R=thibaudm@chromium.org
Bug: v8:11879
Change-Id: I00a559286d67e7e377a36b68803ee30e8fa2f34e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168341
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76987}
On Mac we handle SIGBUS, not SIGSEGV, so the test should access a valid
but inaccessible pointer to trigger the right signal.
R=jkummerow@chromium.org
Bug: v8:11955, v8:12249
Change-Id: I25b93ce40bccc24ef5e84694a7c03c465eb4c51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168344
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76984}
We move some instructions from the test that just disassembles them, to
the test that checks for expected output.
Bug: v8:12207
Change-Id: Ide8954e36c6ad016150bfe45abc1717bed55eb19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171972
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76970}
The function index encoded into the serialized module is already offset
by num_imported_functions. For lazy compilation, however, we added the
number of imported functions another time, which was incorrect.
R=clemensb@chromium.org
Change-Id: I56380e21e74b4d1935ebdbab6ef8cc388de49f2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172761
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76965}
The fix is released now, so we can add the tests to the public repo.
R=ahaas@chromium.org
Bug: chromium:1239116
Change-Id: Ie1489f6bcd934f84222b4631921475c389f778dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172752
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76957}
This CL sets the prototype for the other WebAssembly API objects,
Module, Instance, Table, and Memory.
For Instance, the WebAssemblyInstanceImpl function got inlined, as
there was only one caller, and it made setting the prototype
complicated.
R=jkummerow@chromium.org
Bug: v8:12227
Change-Id: I93b459d69b917b099b27f957fb0e04b7e021bd59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168282
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76954}
This adds a few DCHECKs to ensure that the process-wide memory
protection key is not writable (per thread) in a few strategic places:
- Before switching it to writable (which implicitly checks the initial
state),
- when entering compiled code, and
- in the explicit unit test.
R=jkummerow@chromium.orgCC=mpdenton@chromium.org
Bug: v8:11974
Change-Id: I6037f599afe9009d5e48794eb382eb1979f3ce9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3165060
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76953}
This is a reland of 5dde281c87,
after also fixing the ic-migrated-... test, in which an object died
too early.
Original change's description:
> [compiler] Fix a few test flakes and reenable the tests
>
> Bug: v8:12173
> Change-Id: I2983be9133f8ff4d1740e8eba05a3c29d603dfc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168270
> Auto-Submit: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76939}
Bug: v8:12173
Change-Id: If385e5c826b8470ef67f12705c5171f330f6cd57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171353
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76946}
When dst != lhs, we moved lhs to dst, but dst can be == rhs, so we would
overwrite rhs, and end up comparing lhs with itself, always returning
false. We handle the different aliasing cases in the macro-assembler
function I64x2GtS, to simplify the checks in Liftoff a little bit.
TurboFan does not need to change as it will require dst == lhs when AVX
is not supported.
Bug: v8:12237
Change-Id: Icefa6eb79083c003e93dbbd11ccc419aae4b15d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3169312
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76945}
We move some instructions from the test that just disassembles them, to
the test that checks for expected output.
Bug: v8:12207
Change-Id: I913237427d795ed44539c7294ebbe69330c41dfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163278
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76944}
Make GetValueType to generate only function signatures
to avoid default values in new_object.
Bug: v8:11954
Change-Id: Ia6ebdde0a9c10c56afef29d6db3b3266816210e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158222
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Rakhim Khismet <khismet@google.com>
Cr-Commit-Position: refs/heads/main@{#76934}
... and move methods that use XXX::cast() there.
This will untangle the include cycle that'll happen in a follow-up CLs.
Bug: v8:11880
Change-Id: Iba46bc9b0e0df9530197f57d0469456eb9006e66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3164456
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76932}
We add support for array.get, array.set and array.len operation to the fuzzed module.
Bug: v8:11954
Change-Id: Ic8fd89ec7f7f31e70a40bad831567e50ae49f668
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168624
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Cr-Commit-Position: refs/heads/main@{#76931}
This means we don't need to copy over properties, and accessors stay in
place similar to when we deserialize a custom snapshot.
This slightly changes the semantics of Context::New, so let's see
whether someone depends on this behaviour. We may need to revert if so
(hopefully until we can update the embedder).
Bug: v8:12113
Change-Id: I8325480a00bab5b2bb6ea42274e295b0d4dfc85c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162143
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76928}
The recent change in the delegate semantics was incorrectly implemented
in the interpreter. It only checked that the first opcode of the target
block is a 'try': we also need to skip try blocks when we are already in
their 'catch' or 'catch_all' sub-block.
Use the exception_stack instead, since it already only contains indices
of try blocks that haven't reached their handlers yet.
R=clemensb@chromium.org
Bug: chromium:1249306
Change-Id: I15746b4bfabf3dcf04cfe0f2ad438c573cce65e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168622
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76919}
SIMD is now shipped, so we don't need to pass the experimental wasm simd
flag.
Change-Id: I54090cec575da5eecfd2bf9a455ac5d0ef3f146e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3169313
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76918}
When the input to F64x2PromoteLowF32x4 is a S128Load64Zero, we can skip
the load + promote, and promote directly with a memory operand. The
tricky bit here is that on systems that rely on OOB trap handling, the
load is not eliminatable, so we always visit the S128Load64Zero, even
though after instruction-selector pattern-matching, it is unused. We
mark it as defined to skip visiting it, only if we matched it.
Bug: v8:12189
Change-Id: I0a805a3fce65c56ec52082b3625e1712ea1ee7cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3154347
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/main@{#76917}
Change base::Optional to an alias of absl::optional. Eventually we
should remove it entirely.
Bug: v8:11006
Change-Id: I687d44cc7e7cd0a49a84bcc207231eb6808eef2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476318
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76913}
This fixes the first part of a failing spec test, the other WebAssembly
objects will follow in other CLs.
R=jkummerow@chromium.org
Bug: v8:12227
Change-Id: I7b57b0c518671f0614a88f0477b64e2507435aba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168272
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76907}
When checking for operand interference, if both operands are slots and
one of them is 128 bit wide, check that the slot ranges don't intersect.
R=nicohartmann@chromium.org
Bug: chromium:1248817
Change-Id: Ib18b6e596dbb23427508b7cc07947a0ab4665e85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162141
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76904}
This ports the trap handler implementation for the arm64 simulator
from POSIX to Windows. Apart from different registers being used
for passing parameters, and different access to these register
values in the signal handler, the implementation is exactly the same.
The new logic is being used for sanitizer builds which automatically
target arm64 via the simulator, or if manually compiling an arm64
simulator build on x64. I manually tested the latter.
Also, the existing unit test is enabled for Mac (which was missing)
and Windows now.
R=ahaas@chromium.org, mseaborn@chromium.org
Bug: v8:11955
Cq-Include-Trybots: luci.v8.try:v8_win64_asan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_asan_rel_ng
Change-Id: Ia62405b28808a3cc9f199e3f43a45ffc4bda491b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163256
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76902}
Instead of explicitely splitting the cage into two separate regions, we
now just create a single BoundedPageAllocator to manage the entire
address range of the cage, then allocate the first 4GB for the pointer
compression cage.
Bug: chromium:1218005
Change-Id: I02c53ca8b6dda9074ae6caccc74c32bd6271d4d2
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162044
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76900}
Previously the internal `[[ArrayBufferData]]` property for `ArrayBuffer`
objects reported by the inspector (and used by the DevTools front-end to
identify `ArrayBuffer`s and `WebAssembly.Memory`s using the same backing
store) simply contained a hex string representation of the backing store
pointer. However that unnecessarily leaks internal addresses and more
importantly is not deterministic, which complicates tests (just blew up
on layout tests).
This CL introduces an automatically incremented `BackingStore::id()`,
which is used instead now and is deterministic.
Bug: chromium:1199701, chromium:1163802, chromium:1249961
Change-Id: I8ee47009cd825cfdbe00230f617c87c90508ab2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162144
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76893}
The default value for table entries in WebAssembly tables is null when
the table gets allocated from WebAssembly, but when the table gets
allocated from JavaScript, the default value is undefined when the
table type is externref. With this CL V8 handles the JavaScript case
spec-compliant.
R=manoskouk@chromium.org
Bug: v8:12227
Change-Id: Ic8a1361629d8e5dfb59e2ee22a5e0ae0f6de936d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162045
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76892}
Behind the --wasm-inlining flag, we introduce speculative direct calls
as an alternative to invoking functions through references.
In pseudocode, call_ref(func_ref, args...) reduces to
if (func_ref == function_reference_at(expected_index)) {
call_direct(expected_index, args...)
} else call_ref(func_ref, args...)
The introduced direct call can later get inlined in WasmInliningPhase.
Currently, we always speculate that the reference is the function at
index 0. Proper heuristics, based on liftoff runtime feedback, will come
later.
Bug: v8:12166, v8:7748
Change-Id: Icd1319d3091b436e71906717fd8a2662bfbb8481
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162602
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76884}
JavascriptBuiltinContinuationFrame and BuiltinFrame didn't correctly
handle the receiver when it was included in the argument count.
Bug: v8:11112, chromium:1249941
Change-Id: I4d79bd152ea7e992fa3b87a4de2a509b79fcb37c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3165058
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76881}
... by adding atomic (relaxed) accessor's for a map's
constructor_or_backpointer field, and using them in the two functions.
Bug: chromium:1250216, v8:7790
Change-Id: I3416799cca73792ff5f8963685274ad9afdc6229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162129
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76876}
Reason for revert: There was an out-dated wpt test in blink that
failed after this CL. I adjusted the test expectations in https://chromium-review.googlesource.com/c/chromium/src/+/3162980 so that I can land this CL.
Original change's description:
> Revert "[wasm][externref] Support default value for the table.set"
>
> This reverts commit 6b57898062.
>
> Reason for revert: Fails layout tests: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/13751/overview
>
> Original change's description:
> > [wasm][externref] Support default value for the table.set
> >
> > WebAssembly.Table.set allows a default value instead of the second
> > parameter, which was not supported by V8 so far.
> >
> > R=thibaudm@chromium.org
> >
> > Bug: v8:7581
> > Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> > Commit-Queue: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#76846}
>
> Bug: v8:7581
> Change-Id: I83d9be59c66ece3184b5708e5b8a3b401e4938ed
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163257
> Auto-Submit: Clemens Backes <clemensb@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/main@{#76852}
Bug: v8:7581
Change-Id: I248f836ba4de2a4e3f3d80c00e6f1ac0b46a38d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162608
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76873}
Liftoff needs to be fully implemented for running this test.
Change-Id: Ia229d478fa22d4ce9a715d13b3d2b09a2634ad1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163016
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76870}
This test is added in commit bc3b9332ac
Bug: v8:7748
Change-Id: I8bada39c6fc9ed22f7a25786697aed880738bc9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163286
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76868}
EphemeronHashTable does not trigger interrupts when accessed
(as opposed to calling the WeakMapGet builtin), so it avoids
the use-after-free problem when reading exception metadata
triggers session disconnect while holding a reference
to the session.
Bug: chromium:1241860
Change-Id: I29264b04b8daf682e7c33a97faedf50e323d57c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158326
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76864}
This is a reland of 11045926ca
The first version of this CL uncovered a TSAN failure when not disabling
RCS anymore. The problem was that a background thread was still updating
RCS counters, while the main thread already dumped those values during
tear down. This CL fixes this by dumping counters only after all
background threads are stopped.
Original change's description:
> [test] Avoid disabling of RCS during runtime
>
> Test was flaky since disabling of RCS at runtime is unsafe. Some code
> (e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
> might also DCHECK that RCS is enabled.
> A background thread (sweeping in this case) could've already
> entered such a code path right before RCS is disabled. In this case the
> guard at the entry still saw that RCS is enabled but subsequent DCHECKs
> that ensure that RCS is enabled might fail.
>
> We could fix this by completing the sweeper tasks before disabling RCS
> but there might be other similar tasks which might be run at that point
> in the future (e.g. memory unmapper).
>
> Disabling the flag doesn't even seem to be needed for the initial
> regression test, so it seems simpler to just not disable RCS anymore.
>
> Bug: v8:12026
> Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76845}
Bug: v8:12026, v8:12234
Change-Id: I5cb577051d188d17b02ca7da79a3f1d9aa646cae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162050
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76859}
These tests don't depend on initializing VM (for Context) or even an
isolate, so we can remove the setup code, and use UNINITIALIZED_TEST
(will not even set up an isolate).
Bug: v8:12207
Change-Id: I4b509b95cc8272db22892c32b53464678403dc7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160748
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76854}
This reverts commit 6b57898062.
Reason for revert: Fails layout tests: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/13751/overview
Original change's description:
> [wasm][externref] Support default value for the table.set
>
> WebAssembly.Table.set allows a default value instead of the second
> parameter, which was not supported by V8 so far.
>
> R=thibaudm@chromium.org
>
> Bug: v8:7581
> Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76846}
Bug: v8:7581
Change-Id: I83d9be59c66ece3184b5708e5b8a3b401e4938ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163257
Auto-Submit: Clemens Backes <clemensb@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/main@{#76852}
This reverts commit 16df1dfa13.
Reason for revert: Multiple failures, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/43844/overview
Original change's description:
> [arm64][wasm-simd] Use Cm(0) for integer comparison with 0
>
> Use an immediate zero operand for integer comparison when possible. This
> gives ~1% runtime performance improvement in some benchmarks on Neoverse
> N1.
>
> Change-Id: I727a8104f8e6ca3d122d6b5b8b3d38d7bdd76c47
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158327
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/main@{#76847}
Tbr: zhin@chromium.org
Change-Id: I7039106d885c59aecad24dd8dda4d151b8e1f022
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162053
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76851}
Instead of trying to detect which sanitizer we run on, just allow the
output that any sanitizer would produce.
Note that the regular expression syntax is pretty limited, so we cannot
express this as a single regex.
This removes the single use of {V8_USE_UNDEFINED_BEHAVIOR_SANITIZER}
again, but for completeness I leave it in {macros.h} for now.
TBR=jkummerow@chromium.org
Bug: v8:12226
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_cfi_rel_ng
Change-Id: I37a6d15ebb9fdafbdbee0158ba6c540582c31301
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162046
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76850}
This reverts commit 11045926ca.
Reason for revert: Uncovered TSAN failure
Original change's description:
> [test] Avoid disabling of RCS during runtime
>
> Test was flaky since disabling of RCS at runtime is unsafe. Some code
> (e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
> might also DCHECK that RCS is enabled.
> A background thread (sweeping in this case) could've already
> entered such a code path right before RCS is disabled. In this case the
> guard at the entry still saw that RCS is enabled but subsequent DCHECKs
> that ensure that RCS is enabled might fail.
>
> We could fix this by completing the sweeper tasks before disabling RCS
> but there might be other similar tasks which might be run at that point
> in the future (e.g. memory unmapper).
>
> Disabling the flag doesn't even seem to be needed for the initial
> regression test, so it seems simpler to just not disable RCS anymore.
>
> Bug: v8:12026
> Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76845}
Bug: v8:12026
Change-Id: I154817fc5ddeab68c69c745d08f3d77c48896dc4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162049
Auto-Submit: Dominik Inführ <dinfuehr@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/main@{#76848}
Use an immediate zero operand for integer comparison when possible. This
gives ~1% runtime performance improvement in some benchmarks on Neoverse
N1.
Change-Id: I727a8104f8e6ca3d122d6b5b8b3d38d7bdd76c47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158327
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#76847}
WebAssembly.Table.set allows a default value instead of the second
parameter, which was not supported by V8 so far.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76846}
Test was flaky since disabling of RCS at runtime is unsafe. Some code
(e.g. TRACE_GC) is run only in case RCS is enabled and such code paths
might also DCHECK that RCS is enabled.
A background thread (sweeping in this case) could've already
entered such a code path right before RCS is disabled. In this case the
guard at the entry still saw that RCS is enabled but subsequent DCHECKs
that ensure that RCS is enabled might fail.
We could fix this by completing the sweeper tasks before disabling RCS
but there might be other similar tasks which might be run at that point
in the future (e.g. memory unmapper).
Disabling the flag doesn't even seem to be needed for the initial
regression test, so it seems simpler to just not disable RCS anymore.
Bug: v8:12026
Change-Id: I878f7dd9a7a4abb6a501f7a7651a1240ef2082a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162043
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76845}
Per https://github.com/WebAssembly/gc/issues/234, this implements
"nominal" type definitions with explicit supertypes, and statically
typed RTT-less instructions for allocation and testing/casting.
This should be fully backwards compatible with existing Wasm modules.
Spec: https://bit.ly/3cWcm6Q ("version 4")
Bug: v8:7748
Change-Id: Id5a1399b368fdfad22036cfd66f1bef593e640f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144916
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76844}
This is a reland of a55c82d46b, now also
fixed for UBSan.
Original change's description:
> Reland "[wasm][test] Fix test expectation"
>
> This is a reland of 6f9cde1ee6, with
> special handling for MSan as well.
>
> Original change's description:
> > [wasm][test] Fix test expectation
> >
> > In the mprotect case, there could be one or multiple succeeding writes
> > until we finally crash. Thus do not check that we never successfully
> > write, but just check that the last printed statement is *before* a
> > write.
> >
> > R=jkummerow@chromium.org
> >
> > Bug: v8:12226
> > Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343
> > Commit-Queue: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#76829}
>
> Bug: v8:12226
> Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
> Change-Id: I85ca98be43fc1d933d39a4602194e1771c33007c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162037
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76839}
Bug: v8:12226
Change-Id: I911295b73a385c899a993a729db3a499e58b7cb6
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162041
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76841}
This reverts commit a55c82d46b.
Reason for revert: Fails on UBSan: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20cfi/31712/overview
Original change's description:
> Reland "[wasm][test] Fix test expectation"
>
> This is a reland of 6f9cde1ee6, with
> special handling for MSan as well.
>
> Original change's description:
> > [wasm][test] Fix test expectation
> >
> > In the mprotect case, there could be one or multiple succeeding writes
> > until we finally crash. Thus do not check that we never successfully
> > write, but just check that the last printed statement is *before* a
> > write.
> >
> > R=jkummerow@chromium.org
> >
> > Bug: v8:12226
> > Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343
> > Commit-Queue: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#76829}
>
> Bug: v8:12226
> Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
> Change-Id: I85ca98be43fc1d933d39a4602194e1771c33007c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162037
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76839}
Bug: v8:12226
Change-Id: Ifb0f4b7e87c9c54271f7f3de29b1f1fc6e867f3f
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162040
Auto-Submit: Clemens Backes <clemensb@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/main@{#76840}
This is a reland of 6f9cde1ee6, with
special handling for MSan as well.
Original change's description:
> [wasm][test] Fix test expectation
>
> In the mprotect case, there could be one or multiple succeeding writes
> until we finally crash. Thus do not check that we never successfully
> write, but just check that the last printed statement is *before* a
> write.
>
> R=jkummerow@chromium.org
>
> Bug: v8:12226
> Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76829}
Bug: v8:12226
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Change-Id: I85ca98be43fc1d933d39a4602194e1771c33007c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162037
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76839}
This reverts commit 6f9cde1ee6.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/40332/overview
Original change's description:
> [wasm][test] Fix test expectation
>
> In the mprotect case, there could be one or multiple succeeding writes
> until we finally crash. Thus do not check that we never successfully
> write, but just check that the last printed statement is *before* a
> write.
>
> R=jkummerow@chromium.org
>
> Bug: v8:12226
> Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76829}
Bug: v8:12226
Change-Id: I11ed00268db8dae5c773ed14fda9a343566f910a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3161333
Auto-Submit: Zhi An Ng <zhin@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/main@{#76831}
In the mprotect case, there could be one or multiple succeeding writes
until we finally crash. Thus do not check that we never successfully
write, but just check that the last printed statement is *before* a
write.
R=jkummerow@chromium.org
Bug: v8:12226
Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76829}
