Only the parent of the continuation itself was updated. Also update the
parent of the suspender
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I06684548abe70f4bbda48c12e9e8adda84e1ec27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3726293
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81419}
In crrev.com/c/3714237, we changed the representation of constant
expressions in mjsunit wasm tests to byte arrays. This CL complements
this change by updating the output of --wasm-fuzzer-gen-test to the
new format.
Change-Id: I6a9d861b5abe13621ffd2ceb3a54863b0188b40c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3726294
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81414}
This remodels the tier-up checks on loop back edges to avoid
modifying the cache state by taking temp registers passed in
from the caller, and not causing the instance to get cached.
Additionally, this introduces FreezeCacheState scopes, which
allow us to enforce that certain ranges don't cause any cache
modifications. Conditional jumps require such a scope to be
around, which should help ensure that we don't forget to add
them to any future code we write.
Drive-by cleanup: drop {pinned} lists from a few Load helper
functions. They don't allocate registers (and shouldn't), so
they don't need to know about pinned registers.
Fixed: chromium:1339321
Change-Id: I1c7660418a85259e96c5e0dcfeaf12dab2114e8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3724787
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81411}
- Use the lowered 32-bit signature when linking the inlined and caller
graphs.
- Tolerate non-projection uses of Call nodes when linking the graphs.
These can be left over by Int64Lowering.
- Drive-by: Inline really small functions even if their call count is
low.
Bug: v8:12166
Change-Id: I5b472d3f617f2f23820a5d142102c0a6c5c769dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720715
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81386}
Quite embarassingly, the test that the WTF-8 decoder rejects surrogate
pairs was broken: the trailing surrogate was invalid. (The range of the
second byte for leading surrogates is [A0,AF], and for trailing is
[B0,BF]). Of course the actual functionality was broken, because the
code that detected surrogate pairs called IsSurrogatePair with swapped
arguments.
Bug: v8:12868
Change-Id: Icab5e2e4e200afb3d34f478ab4f98b739ada5645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3723497
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81376}
This CL adds control-path type-tracking for wasm-gc nodes in the
WasmGCOperatorReducer. Nodes now use the types assigned to their
argument nodes, as well as the additional information tracked along
control paths.
Drive-by: Add support for multiple instances of the same node to
appear in control-path-state.
Bug: v8:7748
Change-Id: I73e8f84595609b3a5fb61a2bffeb973182d17676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717994
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81373}
The optimization of a trap inside a branch is being removed. Since it
does not speed-up non-trapping programs, and it is quite narrow, it is
not worth the maintenance cost.
Bug: chromium:1338947, chromium:1338950, chromium:1339153
Change-Id: I5b3f52e2b11d4c5113dd44fe23c14d74124a15f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721617
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81357}
It is an invariant that objects in the shared heap never point into
per-Isolate heaps. This is currently broken by DependentCode. At the
same time, shared maps and other holders of DependentCode are designed
to never invalidate optimized code. E.g., shared maps are effectively
immutable.
This CL does two things:
1. Prevent shared objects from being depended upon
2. DCHECK that shared objects never cause deoptimization
Bug: v8:12547, v8:12761
Change-Id: I0fedae9134a8f786a9200e70f99dba7b38cd2d80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704809
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81340}
Following change in https://github.com/WebAssembly/stringref/pull/22.
This adds two new parsing modes: a strict UTF-8 parsing mode, and a
sloppy mode that should replace invalid subsequences with U+FFFD.
Bug: v8:12868
Change-Id: I03bd8d2a3408c399ce68f7b150d7650908804113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3719919
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81337}
Code for map methods was added a really long time ago but no one ever
brought that to set. Adds new common lowering for both collections and
updates the SetPrototypeHas builtin. My initial testing shows this to
be as much as 50x faster in some cases.
Change-Id: Ifea5be01c9e51013d57ac00bd817759ceace6669
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3709246
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: snek <snek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81330}
Throw a wasm trap when trying to re-enter a suspender that is active or
suspended.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Ic448a15db29de14fb8d6bb8408af8fbaae82a2b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716481
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81326}
If the returned promise rejects, we switch to the suspender's stack and
throw the value.
Re-purpose the WasmOnFulfilled data to also represent the rejecting
case and rename it to WasmResumeData.
R=ahaas@chromium.orgCC=fgm@chromium.org
Bug: v8:12191
Change-Id: I91a301c3c6d9d243efbfabe7263555e11f0d9277
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706606
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81325}
A lot of logic is missing from the Wasm entry for fast api calls.
The majority of the lowering is shared between wasm and js, and uses
the same graph operators, so this adds a common fast api call builder
which can be called from the wasm compiler and the js compiler.
Bug: chromium:1052746
Change-Id: I9dbd82548951b2b155a7b2459714239d0b251d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3708842
Commit-Queue: snek <snek@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81315}
With recent changes, we resolve the promise of e.g. WebAssembly.compile
with the external API, and not the V8-internal API. The external API,
however, also handles microtasks, and depending on the MicrotasksPolicy,
may also execute microtasks immediately. This means the then-handler of
WebAssembly.compile may get executed within all the scopes that were
open when the external API was called. One of the open scopes is the
CancelableTask that finishes WebAssembly compilation.
The deadlock seen in the issue arises now when {quit()} gets called in
the then-handler of WebAssembly compilation. The reason is that
{quit()} terminates the isolate, and during isolate termination, we wait
for all running CancelableTasks to finish. This, however, means a
deadlock, because the task that terminates the isolate is waiting for
itself to finish.
R=jkummerow@chrommium.org
Bug: chromium:1338150
Change-Id: I89243daffc76a456293519e24bfaad88277bb99a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717990
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81311}
- Check that internalized strings always have a computed hash value.
- Check that ThinStrings never have a forwarding index.
- Add a simple test of various property access with
--always-use-string-forwarding-table to make the CF aware of the flag.
Change-Id: Ie047c9f635d5e0ed999208ec3379ef09c395b3f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717988
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81303}
Part 1:
Revert "PPC: skip slow tests on the ppc simulator"
This reverts commit 9dfac00a1d.
Part 2:
Make the slow test faster.
Bug: v8:11111
Change-Id: I8f0291098d29917fa65c4b5b28bf03cbdbe7ebc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714229
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81301}
Initial implementation for concurrent shared arrays. Current implementation exposes a `SharedArray` constructor, but its syntax might
change in the future.
Shared arrays can be shared across Isolates, have a fixed size, have no
prototype, have no constructor, and can only store primitives, shared structs and other shared arrays. With this CL shared structs are also allowed to store shared arrays.
The Backing storage for the SharedArrays is a `FixedArrayBase`. This CL introdces a new ElementKind: `SHARED_ARRAY_ELEMENTS`. The new kind should match the overall functionality of the `PACKED_SEALED_ELEMENTS` kind, but having it as standalone kind allows for easier branching in CSA and turbofan code.
Bug: v8:12547
Change-Id: I054a04624d4cf1f37bc26ae4b92b6fe33408538a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585353
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81285}
The tier-up check in any backwards jumps in a br_table list cause the
instance to get cached if it wasn't cached before. When the branch is
not taken, we must not rely on this caching to have happened.
This is a variant of crbug.com/1314184.
Fixed: chromium:1338075
Change-Id: Id511e98f29ec13f0a38b5595ceb4a607c58b92a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716478
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81279}
This is a reland of commit 5b9401dde4
Now also skip tests that require large amounts of virtual address space
if tsan is enabled as tsan may cause V8 to create a smaller sandbox
which is then unable to allocate the required amount of memory.
Original change's description:
> [sandbox] Also enable the sandbox outside of Chromium builds
>
> Drive-by: include the right header in sandboxed-pointer-inl.h and fix
> missing sandbox initialization in generate-bytecode-expectations.cc.
>
> Bug: v8:10391
> Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81216}
Bug: v8:10391
Change-Id: I141080fdf61a77ef48b22e353e3cfbc1ff816e5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716474
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81277}
Maintaining an AST class just for testing constant exressions does not
seem justified. This CL changes constant expressions in mjsunit tests
to be represented with bytes, like regular expressions.
Change-Id: If5ec5f4d863176952442b1a7e2fec8a61e385971
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714237
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81266}
Before we assumed that no exception can be thrown when specifying a
function to be used as an async hook, but that's not the case when e.g.
the object passed to createHook is a proxy trapping on property access
and the trap throws an exception.
Bug: chromium:1337629
Change-Id: I7bd7893cd274afb6e642ed18aacb9e203f7fdd96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714233
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81258}
Exceptions should propagate inside the logical stack, which can consist
of multiple wasm stack segments. When the outermost frame of the current
segment is reached, pick up the parent stack and continue the search
from there, and update the state to reflect the implicit stack switch.
Drive-by: cleanups.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191, v8:12960
Change-Id: Ia5cb39a6ae197fb68e635f986952419dc43c7b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695376
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81208}
This is a reland of commit 76a07814b2
Changes compared to original:
- Add WasmArray::SetTaggedElement, which uses write barriers.
- In Factory::NewWasmArrayFromElementSegment, the new array may have
moved to OldSpace until it is initialized. Therefore, it needs write
barriers; use the new method for that.
- Small readability improvements.
Original change's description:
> [wasm-gc] Implement array.init_from_elem
>
> Bug: v8:7748
> Change-Id: I65dbb496302045820063bd0f4f9ea054e6a645bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695580
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81128}
Bug: v8:7748
Change-Id: Ic5def1886f662bddce72b8eaea274eb5e8ec0c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704513
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81196}
For FixedDoubleArrays that are not aligned on 8 bytes, the SIMD fast
path of array.IndexOf actually falls back on a scalar loop. Because of
how this loop was written, it was failing to see that 0.0 == -0.0.
Bug: chromium:1335445
Change-Id: Idf70fd3ed9950e5b2b7cc72bb2ebca6879b3a04e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702803
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81163}
This CL adds serialization and deserialization
support for ArrayBuffer and TypedArray.
TODOs:
- Support resizable ArrayBuffer.
- Support detached ArrayBuffer.
- Support shared ArrayBuffer.
Bug: v8:11525
Change-Id: Ic9267a78e427ee20d55f2f0483b677eeee5c214b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688896
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81136}
The native module cache makes it difficult to test deserialization,
because the native module just gets loaded from the cache instead of
deserializing the serialized module. This CL adds a new flag,
--wasm-native-module-cache-enabled, to control whether the native module
cache is enabled or not. The cache gets disabled by handling all modules
like asm.js modules when the cache gets disabled, as the cache is not
used for asm.js.
The name of the flag is positive (i.e.
`enabled` instead of `disabled`) to avoid double negation. The flag is
true by default, and set to false in tests.
R=thibaudm@chromium.orgCC=clemensb@chromium.org
Bug: v8:12964
Change-Id: If2b96a95ccf37f2eb8a868ad1661c3325c1048f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3703836
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81132}
This is a reland of commit c8c176190a
This CL includes:
- crrev.com/c/3679846 Add condition use_ic to the removing the optimized OSR code logic
- crrev.com/c/3686589 Add out of bytecode array to break condition of removing OSR code cache logic
- Add JumpLoop nesting level 0 to break condition of removing OSR code cache logic
- Change to use Deoptimizer::DeoptimizeFunction() to deoptimize OSR code
Original change's description:
> [compiler] Remove the optimized OSR code if deoptimizing at inside of loop
>
> If the optimized code is deoptimized and the deoptimized exit offset is
> inside of the optimized OSR code related loop, the optimized OSR code is
> also out of date, remove the optimized OSR code, it will avoid hit the
> optimized OSR code and soon later deoptimization of the optimized OSR
> code.
> This CL will reduce deoptimization. E.g. Deoptimization of JetStream2
> case navier-stokes function addFields is reduced from twice to once.
>
> Change-Id: I5bbf3039e916c3736b5b967d1f36b6ea90cfd40b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3648219
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Tao Pan <tao.pan@intel.com>
> Cr-Commit-Position: refs/heads/main@{#80826}
Bug: chromium:1330444
Change-Id: I97a466ddfa764438b45f33c6ae33cb921d57278d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3690451
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#81110}
Add a new --wasm-max-module-size flag to replace the unused and more
specific --experimental-wasm-allow-huge-modules flag.
The new flag can be used in fuzzers to reduce the maximum allowed module
size, avoiding OOM on some systems (like 32-bit ASan builds).
R=ahaas@chromium.org
Bug: chromium:1334577
Change-Id: I2830d407c5b01be21a47b21392c1210061c40b20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695267
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81102}
In particular, this CL adds support for:
- exception handling
- source positions
- OSR
- various numeric operations and conversions
Since the test suite now passes with `--turboshaft`, this also adds a
new variant for Turboshaft and enables it on some bots.
Bug: v8:12783
Change-Id: Ia2dd2e16f56fc955d49e51f86d050218e70cb575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669251
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81074}
Add a missing check to reject illegal sections.
The test is added in three forms, to give fuzzers more food: A fuzzer
regression test for the streaming fuzzer, a unit test for the streaming
decoder, and an mjsunit test for streaming compilation.
Drive-by: Remove a redundant line in the synchronous decoder (this is
already handled by the following statement.
R=ahaas@chromium.org
Bug: chromium:1335023
Change-Id: Ic8c3b301f1b58981c7d68eafcffc89531ed2c64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3698549
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81071}
This CL splits two mjsunit files and skips the ones
which take the longest on the simulator and cause a timeout.
Change-Id: I89be764dc2d7684b401690a23bf53a3ef6384d16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693667
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81065}
- Functions related to table initialization now return an optional
{MessageTemplate} if they fail. This is used to emit the correct error
message in one test.
- InitExprInterface now uses {MessageTemplate} to describe errors.
Change-Id: I2428f7823859b95d14b6e81c8200f78da4510ceb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695579
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81045}
Context: https://github.com/WebAssembly/exception-handling/pull/197
This change adds the optional {traceStack: <bool>} parameter to the
WebAssembly.Exception constructor. When set to true, this captures the
stack and sets the `stack` accessor on the exception object.
R=jkummerow@chromium.org
Bug: v8:8091
Change-Id: I4430b6317b27ec62f11e951fbe95ee480ac72d37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688402
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81041}
In typed-optimization, Turbofan optimized NumberFloor(NumberDivide(...))
patterns where both inputs are known to be of Unsigned32 type, but the
replacement couldn't be typed consistently. This CL introduces a new
operator Unsigned32Divide, which has the same semantics, but can be
typed consistently and thus allows the simplified lowering verifier to
validate the graph correctly.
Bug: v8:12619
Change-Id: Iad77154d3d840c94edfd3ab91ffa37c840da0bc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644790
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80967}
Calling memset directly is faster than std::fill for multi-byte element
types.
Change-Id: I83b997740146688f87b86901825e31d6644bc25b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687700
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80945}
It mostly worked out of the box. Only the dictionary mode prototype
chain walk code paths had to be updated.
Bug: v8:11111
Change-Id: Ia8336964d29304916a34e305f32bb33bb06e211a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683340
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80935}
This CL adds the serialization and deserialization for
properties in class.
TODO: we could use serialized start_position and length
in function to add ClassPositions property to class.
Bug: v8:11525
Change-Id: I065039932b3c10c6b757b331aba0ced36eba84e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3682878
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80927}
We introduce a typing phase into the Turbofan compilation pipeline for
wasm-gc. It has two functionalities: (1) to type nodes that were not
typed during code generation (mainly phi nodes) and (2) to narrow types
as much as possible.
The following nodes are handled, which should be enough for our
purposes: TypeGuard, WasmTypeCast, AssertNotNull, Phi, LoadFromObject,
and LoadImmutableFromObject.
Loop phi types are computed by first assigning the type of the
non-recursive input, and updating once we have the type of the recursive
inputs, and repeating this process to a fixed point.
Drive-by: Remove the narrowing of function signatures during wasm
inlining, as it created some issues and should not be needed after this
series of changes.
Bug: v8:7748
Change-Id: I8a72488d5c221c4ae8257fc5abf6f0368cf10e96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678208
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80912}
The OOB check belongs in ValidateIntegerTypedArray according to the
spec.
This also fixes the error types for OOB TypedArrays when doing Atomics:
OOB TypedArrays should get a TypeError, not RangeError.
Bug: v8:11111
Change-Id: Ice2e5695d69d84b2c20a4cf8f06880673d901a91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676859
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80898}
This is a reland of commit ea9a1f1cbe
Changes since revert:
- Make the state field uintptr-aligned since arm64 faults on
atomic accesses to non-naturally aligned addresses.
Original change's description:
> [shared-struct] Add Atomics.Mutex
>
> This CL adds a moving GC-safe, JS-exposed mutex behind the
> --harmony-struct flag. It uses a ParkingLot-inspired algorithm and
> each mutex manages its own waiter queue.
>
> For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
>
> Bug: v8:12547
> Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80789}
Bug: v8:12547
Change-Id: I776cbf6ea860dcc6cb0ac51694a9b584b53d255c
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3673354
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80875}
This CL adds the serialization and deserialization
for properties in function. And we only support fast
properties in property array now.
Bug: v8:11525
Change-Id: If0bb3fee400ca957009d046ed74b92d8192c2514
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650675
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80858}
This CL adds a moving GC-safe, JS-exposed mutex behind the
--harmony-struct flag. It uses a ParkingLot-inspired algorithm and
each mutex manages its own waiter queue.
For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
Bug: v8:12547
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80789}
This test had been skipped since it was added in
4a416dbbe1.
Bug: v8:9380
Change-Id: I700f83fa4242baf44dd260fbc74520abf05101dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3670052
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80766}
We inline array allocation for wasm-gc in the TF graph by using
AllocateRaw nodes. Additionally, we use memset to initialize large,
zero-initialized arrays. These changes give measurable speedup in some
benchmarks.
Bug: v8:7748
Change-Id: Icbd37d0fe673c673379139b96d0e1c175e95e357
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666618
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80762}
Bug: v8:12868
Also adds the equivalent of Utf8Decoder, but for WTF-8.
Change-Id: I1548a44b0aea912cdd429eb85be4dfc606355cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660257
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80750}
The generated code checks if the receiver is a JS_API_OBJECT and if the
receiver requires an access check, and if not it lowers the call to an
API call.
We also add compilation dependencies on the protector cell to deopt if
our invariants change. (Note - the actual invalidation of these cells
will be implemented in a follow up CL)
Bug: v8:11321
Change-Id: I15722f1e5fac7176e292da4a35186e4609636aba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719563
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80748}
Previously the LookupIterator ignores private symbols
(including private names) for the access check. This patch
removes these exceptions so that they are always checked.
Drive-by: removes the unused should_throw parameter in
Runtime::DefineObjectOwnProperty()
Bug: chromium:1321899
Change-Id: I9677b1e377f01d966daa1603eee1ed9535ffab92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623419
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80700}
Add an implementation of BranchIfInt32Compare, which is emitted whenever
a compare op is immediately followed by a branch.
Bug: v8:7700
Change-Id: I2c56d9de199bac8de33b33201f8614aee8e9894e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647693
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80694}
Bug: v8:12868
Also adds wtf8.cc, wtf8.h to src/wasm, to implement WTF-8 validation and
possibly other utilities. Also fixes a bug when parsing the string
literals section; I had misunderstood the way the unordered/ordered
sections mechanism worked.
Change-Id: I3c4205e0872379a69575f84ba33e0090a9d8d656
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652789
Commit-Queue: Andy Wingo <wingo@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80674}
Add Int32/Float64 nodes for:
* Subtract
* Multiply
* Divide
and additionally Int32 nodes for
* BitwiseOr/And/Xor
* ShiftLeft/Right/RightLogical
The latter ones don't have Float64 equivalents since they're implicitly
Int32 operations. In the future we'll add support for Number feedback by
adding Float64-to-Int32 conversions and using the Int32 nodes.
The divide node does an Int32 division and deopts if there's a remainder
to the division -- we may want to make it output a Float64 instead if we
think that's more likely in real-world code. There's also no peephole
optimisations for constant operations, which would generate much better
code, especially for shifts.
Bug: v8:7700
Change-Id: Ief1d24b46557cf4d2b7929ed50956df7b0d25992
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652301
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80670}
Enforce the parent context has a smaller id, this time more forcefully.
Bug: v8:11525,v8:12820
Change-Id: I05bf675545b81b818eebfcaa40ee6bb93f5bcf9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652792
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80666}
Part of the improve error messages initiative.
Based on a resource of JSON.parse() errors found at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
added support for:
- 'Bad control character in string literal'
- 'Bad Unicode escape'
Previously JSON.parse('"a\bz"') would output:
SyntaxError: Unexpected token in JSON at position 2
Now the output is:
SyntaxError: Bad control character in string literal in
JSON at position 2
Previously JSON.parse("[\"\\t\\u") would output:
SyntaxError: Unexpected end of JSON input
Now the output is:
SyntaxError: Bad Unicode escape in JSON at position 6
Bug: v8:6551
Change-Id: I3ba5450c41b8a388643a15bc58e4e3fc75855d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652254
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Issack John <issackjohn@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80642}
Goal is to keep the tree green while the issue is investigated.
No impact on shipped product since shared-memory is flag-guarded off.
Bug: v8:12883
Change-Id: I9a434bdebc781023fa6693eef47db6dbe81cd4bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653320
Auto-Submit: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 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@{#80619}
Loading from/storing to the same field with incompatible mutabilities
is possible in unreachable code, specifically when a value is cast to
two different types with incompatible mutability for the same field
offset. Therefore, we allow this pattern in CsaLoadElimination.
When we detect it, we emit an Unreachable node to immediately crash the
program in case this unreachable code is somehow executed.
Bug: v8:7748, v8:12874
Change-Id: Ieb359d3e1b9f7bc4a91c556af2bba0507526d20e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644806
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80587}
Part of the improve error messages initiative.
Based on a resource of JSON.parse() errors found at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
Previously JSON.parse(NaN) would output:
SyntaxError: Unexpected token N in JSON at position 0
Now the output is:
SyntaxError: "NaN" is not valid JSON
Previously JSON.parse("{a:1}") would output:
SyntaxError: Unexpected token a in JSON at position 1
Now the output is:
SyntaxError: Expected property name or '}' in JSON at position 1
Bug: v8:6551
Change-Id: Ic9fad1fdbd295e1302805b81e6603fc526121960
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3513684
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Issack John <issackjohn@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80567}
Bug: v8:12868
This wires up the parser and the decoder interface for stringref. All
of the interfaces throw UNIMPLEMENTED, however.
Change-Id: If8cb131032e425a5672f793c6e4c24ddd188aebc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645115
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80545}
This CL adds two experimental JS builtins to convert between
i16 Wasm GC and JS strings. This is a non-standard experimental
feature only available with the flag --wasm-gc-js-interop.
WebAssembly.experimentalConvertArrayToString(array, start, count)
Convert the `count`-many WTF-16 code units starting at index `start`
into a JS string. Throws a TypeError if `array` is not an i16 array,
or if `start` and `count` are not numbers or not in range.
WebAssembly.experimentalConvertStringToArray(string, sampleArray)
Convert `string` to an i16 array. The `sampleArray` parameter needs
to be an arbitrary i16 array, which is only used to extract the rtt.
Throws a TypeError if `string` is not a string or `sampleArray` is not
an i16 array.
Change-Id: I7ac2f6bd89b8f638427f61da1bb01ccba90d735b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642301
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80505}
The IsValidSectionCode function shouldn't include internally-used
numeric identifiers of well-known optional sections.
Fixed: v8:12867
Change-Id: I9d894ee57157455e92a17ddcde94f32f05fb038d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644612
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80494}
Hexadecimal/octal/binary BigInt property names should be converted
to decimal, i.e. the following object literals should all be equivalent:
var o = {0xF: 1}, p = {0xFn: 1}, q = {15: 1}, r = {15n: 1}.
Test case by yangwenming@bytedance.com, uploaded at
https://chromium-review.googlesource.com/c/v8/v8/+/3634937
Fixed: v8:10600
Change-Id: Ie1d8a16e95697cd31cbc0784843779c921ce91fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642302
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80490}
This adds a non-standard, unsafe instruction for performance
experiments: ref.cast_nop_static behaves like ref.cast_static
as far as static types are concerned, but emits no code.
Bug: v8:7748
Change-Id: Ic5797a941146a06d7c6ff249d8e29919145d8ea1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3639206
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80471}
This CL adds the array type flag to distinguish between
sparse array and dense array and adds serialization
and deserialization for sparse array.
Bug: v8:11525
Change-Id: Ia302af017d6f52924256a2b3fa9e3d2b34caa442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629739
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80449}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
First version: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Fix: initialize builtin_objects_handle_
Bug: v8:11525,v8:12820
Change-Id: Ia2b5d41af5d7f577f1b02356b22a8760963009e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3635718
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80430}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
Bug: v8:11525,v8:12820
Change-Id: If72695d46bdfc8bf7e477471be1264b668551854
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80419}
This is a reland of commit 507fa4d7f5
This CL moves the NewJSObjectFromMap after deserializing object properties with dictionary map and fixes the DCHECK failure in JSReceiver::HasFastProperties when triggering GC.
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I88422d698aa03fb7d3b21b5709eec2d0cf306256
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629738
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80374}
Consider the following
* A ValueNode has inputs A and B
* Input A has later uses, input B doesn't
* The ValueNode's result must be in the same register as A
It can then happen that UpdateUses frees B, and the result allocation
emits a gap move from A's register to B's old register (now free) to
preserve the value of A when the ValueNode writes into its register.
This gap move is emmitted before the ValueNode start, which means that
it clobbers B.
Now, UpdateUses only clears registers _after_ node result allocation, so
that the known free registers are still the ones before updating uses.
Done naively, this would have bad consequences -- in the case where A
has no later uses, it would still force the regalloc to save its value
thinking that it is still live. So, this patch also introduces a concept
of "AllocationStage" where we're either allocating at the start or end
of a Node. Inputs are allocated at the start, results at the end. When
walking registers during an allocation, nodes whose lifetimes end at the
current node are considered to be dead at the "end" allocation stage,
and we are allowed to a) use their registers, and b) drop them without
preserving their value.
Bug: v8:7700
Change-Id: I5ca764ed04b12269f189577e81eb7e2a27cd1b09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625978
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80371}
This reverts commit 507fa4d7f5.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38308/overview
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I0d236a9937a5942b387553a61991716321b063e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629541
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80368}
This CL adds the serialization support for object properties
with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
Bug: v8:11525
Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80366}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
https://crrev.com/c/3571817 introduced a bug that string table lookups
failed on SlicedStrings with a start offset of 0.
This CL fixes the issue by re-using the already computed hash only
if the length of the source string matches the length of the string to
lookup.
Bug: chromium:1320179, chromium:1321573
Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80309}
This is a reland of commit 9145388055
Fixed: properly reference the ClearedValue in CSA (i.e. without
the cage_base upper 32 bits).
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161,chromium:1320189
Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80306}
This reverts commit 9145388055.
Reason for revert: Breaking the Fuchsia Deterministic Builder
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161
Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80287}
- Supports Float64 Add for SmiAdd bytecode
- Adds a Float64Constant and ChangeInt32ToFloat64 nodes
- Converts floats to tagged in Phi node inputs
- Fixes spill double representation
- Fixes materialisation during a deopt of a double in the stack
Bug: v8:7700
Change-Id: I9217a64313b4bd5d0015f935c23771ecf9a2c7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610426
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80255}
Add an unboxing double field load node, and fix a couple of locations
where it might be used enough to pass tests.
Bug: v8:7700
Change-Id: Ic134484e87a4fa363cbd8a3de667ac8e8116d502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610623
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80221}
This fixes the ordering of DCHECKs which expect the value to not be in
the free list yet when it is dropped.
Bug: v8:7700
Change-Id: Ifb85d0e20cfe5c083d1f2bc971817143265fdc7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610444
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80218}
CheckedFloat64Unbox mutates the input value, but the register allocator
does not expects this behaviour and propagates a wrong value in the register.
In particular we deopt with the wrong value if the second Float64Unbox
in a Float64Add needs to deopt.
This fixes the input value after we convert to double.
Bug: v8:7700
Change-Id: Ib89573e9f728dc3a34b817fc84f1afcb96f14d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610422
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80214}
The JS import returns a tagged value, not a value of the machine
representation that corresponds to the signature's return type, since it
hasn't been converted yet.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I0783af85eed9c5d25347200540e3e4eee48edfd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3464036
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80213}
This logic was confused in the presence of inlined frames; the
deopt exit offset would point inside the innermost inlined frame
while we incorrectly assumed it points at the outermost frame.
Fix this by always referring to the bytecode offset of the outermost
frame.
Bug: v8:12161
Fixed: chromium:1320094
Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80212}
This CL includes count value to InvalidCountValue error message to make
it easier to dignoise RangeError of String.prototype.repeat. When
InvalidCountValue error throw, we could not know it's
caused by which count value if count value is not included.
Bug: none
Change-Id: I16e6693da0fc3b181241cb90daca27957f59c77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593574
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80198}
When passing anyref-typed things to Wasm, we cannot expect that
all functions are WasmExternalFunctions. Instead of adding a
relatively expensive type check to such calls, this patch disables
function unwrapping for anyref-typed values.
Fixed: v8:12789
Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80179}
- For simplicity we call a builtin when allocating a number.
- Elision of boxing/unboxing nodes will be done in a followup CL.
Bug: v8:7700
Change-Id: Iec4422d84c6597d3369ab512a1662adb0f077c98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602514
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80178}
Table.set has two arguments, the table index and the value. Therefore
Table.set was defined with a length of 2. However, the value argument is
optional, so the length should actually be 1.
Change-Id: Ica2ea13a8e78c974cb011df2b5dc99f8e7eb4bcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398496
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80176}
This is a reland of commit 91da38831d
Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
on arm64.
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80167}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I3d960751c798ac657a6122598154e36d9d504c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606489
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80163}
This reverts commit 91da38831d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@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@{#80148}
This CL switches over our OSR system to be based on the feedback
vector osr caches.
- OSRing to Sparkplug is fully separated from OSR urgency. If
SP code exists, we simply jump to it, no need to maintain an
installation request.
- Each JumpLoop checks its dedicated FeedbackVector cache slot.
If a valid target code object exists, we enter it *without*
calling into runtime to fetch the code object.
- Finally, OSR urgency still remains as the heuristic for
requesting Turbofan OSR compile jobs. Note it no longer has a
double purpose of being a generic untargeted installation
request.
With the new system in place, we can remove now-unnecessary
hacks:
- Early OSR tierup is replaced by the standard OSR system. Any
present OSR code is automatically entered.
- The synchronous OSR compilation fallback is removed. With
precise installation (= per-JumpLoop-bytecode) we no longer
have the problem of 'getting unlucky' with JumpLoop/cache entry
mismatches. Execution has moved on while compiling? Simply spawn
a new concurrent compile job.
- Remove the synchronous (non-OSR) Turbofan compile request now
that we always enter available OSR code as early as possible.
- Tiering into Sparkplug no longer messes with OSR state.
Bug: v8:12161
Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80147}
TurboShaft is a new, CFG-based IR for TurboFan.
This CL adds the basic IR and bidirectional translation from/to
TurboFan's sea-of-nodes-based IR for some common operators (still
incomplete even for JS).
Bug: v8:12783
Change-Id: I162fdf10d583a9275a9f655f5b44b888faf813f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563562
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80136}
- In DeserializeContext, scope info local values
snapshot is in order of `name,value,name,value`,
and we should ReadValue after ReadString.
- Support non-inlined ScopeInfo locals, use
NameToIndexHashTable to serialize and deserialize
scope info local values when its local count is
more than kScopeInfoMaxInlinedLocalNamesSize.
Bug: v8:11525, v8:12820
Change-Id: I6ea2c498b594bed7ba8ca5be6af2ab9f0d39aa2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600531
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80130}
As per https://tc39.es/ecma262/#sec-hostimportmoduledynamically defined,
referencingScriptOrModule in HostImportModuleDynamically can be a Script
Record, a Module Record, or null.
So to https://tc39.es/proposal-shadowrealm/#sec-shadowrealmimportvalue,
the HostImportModuleDynamicallyCallback is been invoked with a `null`
resource_name. This may not be considered a breaking change as the
parameter resource_name is defined as Local<Value>.
Updates d8's DoHostImportModuleDynamically to handle null resource_name,
and resolve the dynamically imported specifier relative to the executing
script's origin. In this way, we have to set ModuleEmbedderData.origin
even if the JavaScript source to be evaluated is Script. Also, a
ModuleEmbedderData is created for each ShadowRealm to separate their
module maps from the initiator context's.
Bug: v8:11989
Change-Id: If70fb140657da4f2dd92eedfcc4515211602aa46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522883
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80118}
This CL extends GetIterator to check whether the result of
calling @@iterator is JSReceiver and throw SymbolIteratorInvalid
if it's not JSReceiver.
GetIterator bytecode involves 3 steps now:
- method = GetMethod(obj, @@iterator)
- iterator = Call(method, obj)
- if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added]
New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which
is used when lazy deopt is triggered by call @@iterator.
Related spec: https://tc39.es/ecma262/#sec-getiterator.
Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks.
Bug: v8:9489
Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80112}
In the simplest way possible.
Bug: v8:7700
Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80089}
Add a --maglev-inlining flag, and add some half-baked support for
inlining functions when there is call feedback.
When the flag is enabled and there is call feedback, we create a nested
MaglevGraphBuilder for the current graph, and pause building the graph
of the outer function. We manually set up its prologue to set up its
frame with the arguments pass into the call, build the body with the
nested graph builder. This inner builder knows that it is building an
inlined function, and all Return bytecodes will instead emit a Jump to a
single merge block at the end of the function, where execution of the
outer function can resume.
These inner function basic blocks are wired into the outer graph with
new JumpToInline and JumpFromInline control nodes. The idea is that
subsequent passes will know what the inline function is, and will use
these to manage the function stack (particularly for codegen and
especially deopts).
Bug: v8:7700
Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80077}
As ecma262 normative change https://github.com/tc39/ecma262/pull/2683,
exception thrown on PromiseResolve the broken promises need to be caught
and use it to reject the promise returned by
`AsyncGenerator.prototype.return`.
AsyncGeneratorReturn didn't handle the exception thrown by Await. This
CL add an exception handler around it and pass through the caught
exception to the returned promise and resume the generator by
AsyncGeneratorAwaitResume if the generator is not closed, otherwise
reject the promise by AsyncGeneratorReject and drain the queue.
Bug: v8:12770
Change-Id: Ic3cac4ce36a6d8ecfeb5d7d762a37a2e0524831c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581158
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80066}
The fix is merged to all channels, add the regression test.
R=thibaudm@chromium.org
Bug: chromium:1314184
Change-Id: I7b7ca13ff34b19c3dbb727d248619dc1ff874873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596161
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80044}
The roundss / vroundss instruction is only available on AVX or SSE4_1
hardware. Thus bring back the old code path with much longer code for
such old hardware.
R=tebbi@chromium.org
Bug: chromium:1314363
Change-Id: I79a58627c8b406817330e9f9601234cea28182c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578642
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79914}
Some test variants and fuzzers set their own GC interval, so the flag
specified in the regression test causes flag contradictions.
The test failure was flaky anyway, so this change is only a slight
reduction in reproducability, and the test will still be used as seed
for the fuzzers.
R=machenbach@chromium.org
Bug: chromium:1313475
Change-Id: I7c7084ab34fe46d691b841921d42a487cc8a1cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576114
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79845}
A worker might be terminated while creating a new Realm. While this was
handled mostly correctly already, a DCHECK was places slightly too
early, which is fixed by this CL.
Also, we avoid printing an error message if we fail to install an
extension due to isolate termination. As this is externally triggered,
it's not really an error condition.
R=jkummerow@chromium.org
Bug: chromium:1313475
Change-Id: I67b7fd27002d9b9a33439378d8336fefb2a2371a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571811
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79825}
With this CL, spilled parameters with ref type in a call to wasm
function, will be placed at a consecutive area in the generic
JSToWasmWrapper frame as WasmCallDescriptor expected.
Bug: v8:12722
Change-Id: I8b82f35b712a32b87abf5100ec46ee499a8178bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563445
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79805}
This flag was a leftover from very early Turbofan days and serves no
purpose. Non-OSR TF code automatically uses function context
specialization (FCS) when appropriate without looking at the flag
value. OSR TF code should never use FCS since it is cached by the
SharedFunctionInfo (not by the JSFunction).
Bug: v8:12161
Change-Id: Ifb5a10918dbdf34a7164f7e665a230698b793e9e
Fixed: chromium:1313419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571895
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79802}
The FastArray path for Array#groupBy and Array#groupByToMap does not
recheck the input array's length each iteration. This is incorrect since
the grouping callback can truncate the length, and we should deopt to the
generic path when this happens.
Bug: chromium:1312838, v8:12499
Change-Id: Id3a4973e9960500a2f29ed63281ea721777d4dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570342
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79787}
HeapAllocator didn't fall back to old space allocation when the
heap had no map space.
Bug: v8:12578, chromium:1313119
Change-Id: Ic02334f42f9fb80a8a9dcf99a94a7ac16da24053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570423
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79776}
If we have a smi operation in the feedback vector, we emit SmiTag
Int32AddWithOverflow and SmiUntag nodes, instead of a generic
operation binary node.
Change-Id: Idb9ce2b60289fbe492bf269793660b32de23e2b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560641
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79775}
This includes two fixes:
1. For dynamic tiering, the budget must always be reduced when jumping
backwards, otherwise we might never trigger tier up, which makes the
loop non-interruptible (because the tier-up check replaces the stack
check).
2. The d8 worker implementation also needs to terminate the isolate via
an interrupt, in addition to scheduling a task, because the worker
might never return to the event queue.
This CL also fixes one of the failure modes of the inspector fuzzer
(see https://crbug.com/1180018).
R=jkummerow@chromium.org, marja@chromium.org
Bug: v8:12767, chromium:1180018
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: Ia01d1725fc14931d2ea54c4769c4ee93f866ed63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568470
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79773}
This changes the logic for generating method names in `error.stack` to
prepend an inferred type name only when the function name is a valid
ECMAScript identifiers and does not equal the inferred type name, to
(1) give developers more control over the exact name shown in
`error.stack`, as well as
(2) avoid confusion in the presence of renaming of local variables.
Previously we'd leave the function name as-is if it was prefixed by the
inferred type name, but that condition is unnecessarily strict, and led
to a bunch of inconsistencies around special names like
`<instance_member_initializer>` where this dynamic approached often
prefixed it with the correct type name, but also sometimes got it wrong
and prepended `Object.`, which is very unfortunate and misleading.
Specifically for these special names, we'll add logic later in the
parser to infer a useful (complete) name.
The design doc (https://bit.ly/devtools-method-names-in-stack-traces)
contains more background and examples of why we do this change.
Doc: https://bit.ly/devtools-method-names-in-stack-traces
Fixed: chromium:1294619
Bug: chromium:1283435
Change-Id: Ib8b528ba25255dcd07e9d11044c562c11d699bcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565724
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79748}
This is a reland of commit 3ce690eef2
Changed for the reland:
- Remove the currently-unused BytecodeArray member to avoid MSAN
failures.
- s/return/continue/ in optimizing-compile-dispatcher.
Original change's description:
> [osr] Basic support for concurrent OSR
>
> This CL adds basic support behind --concurrent-osr,
> disabled by default.
>
> When enabled:
> 1) the first OSR request starts a concurrent OSR compile job.
> 2) on completion, the code object is inserted into the OSR cache.
> 3) the next OSR request picks up the cached code (assuming the request
> came from the same JumpLoop bytecode).
>
> We add a new osr optimization marker on the feedback vector to
> track whether an OSR compile is currently in progress.
>
> One fundamental issue remains: step 3) above is not guaranteed to
> hit the same JumpLoop, and a mismatch means the OSR'd code cannot
> be installed. This will be addressed in a followup by targeting
> specific bytecode offsets for the install request.
>
> This change is based on fanchen.kong@intel.com's earlier
> change crrev.com/c/3369361, thank you!
>
> Bug: v8:12161
> Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79685}
Bug: v8:12161
Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79746}
This CL removes two obsolete regression tests that were taking too
long on debug engine builds.
Bug: v8:12753
Bug: v8:12754
Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79727}
In DisassembleFunction runtime, function may have available
optimized code and we could directly set the optimized code
for the function like in CompileLazy if it's not compiled,
which avoids calling Compiler::Compile and failed in
DCHECK(!function->HasAvailableOptimizedCode()).
Bug: v8:12762
Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79722}
Lock mutex for shared isolate in global safepoints, such that e.g. the
StringTable can use isolate->heap()->safepoint()->AssertActive() even
for shared isolates.
Bug: v8:11708, v8:12749
Change-Id: I8d99203581dfa2d7225846e19fa981300f88589e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563138
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79715}
Skipped test: https://crrev.com/c/3561199.
This is a reland of commit 6e2c9bb265
Original change's description:
> [serialize] copy bytes for non detachable array_buffer
> in WriteJSArrayBuffer when array_buffer is not in
> array_buffer_transfer_map_
>
> According to https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal
> steps 13.3.2-4, should normally serialize array buffer which
> is not detachable.
>
> Bug: v8:12703
> Change-Id: I4554c5d07ae85e1a96a728ebba04c6a071575f6f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518910
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79466}
Bug: v8:12703
Change-Id: I1ad1b8159ac7b13011831a4590e8577e954db946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557689
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79714}
Add an array of canonical rtts on the isolate. Each wasm instance
copies its rtts from there, based on the type index -> canonical index
mapping in the module.
Bug: v8:7748
Change-Id: I0958686c51ecab15a3215a0da3bee1ad6d543cb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548821
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79712}
The current safety margin between the JS stack limit and the actual
boundary of the stack space reserved by the simulator can be overrun by
a large frame.
Raise this margin to 4KiB, corresponding to the "large frame" threshold.
This ensures that the stack check is executed before the frame is
allocated if the frame is larger than this margin.
R=clemensb@chromium.org
Bug: chromium:1308333
Change-Id: I3e1a51bb36c630c7e37e58679971392dada2a83e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560435
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79711}
This reverts commit 3ce690eef2.
Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188
Original change's description:
> [osr] Basic support for concurrent OSR
>
> This CL adds basic support behind --concurrent-osr,
> disabled by default.
>
> When enabled:
> 1) the first OSR request starts a concurrent OSR compile job.
> 2) on completion, the code object is inserted into the OSR cache.
> 3) the next OSR request picks up the cached code (assuming the request
> came from the same JumpLoop bytecode).
>
> We add a new osr optimization marker on the feedback vector to
> track whether an OSR compile is currently in progress.
>
> One fundamental issue remains: step 3) above is not guaranteed to
> hit the same JumpLoop, and a mismatch means the OSR'd code cannot
> be installed. This will be addressed in a followup by targeting
> specific bytecode offsets for the install request.
>
> This change is based on fanchen.kong@intel.com's earlier
> change crrev.com/c/3369361, thank you!
>
> Bug: v8:12161
> Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79685}
Bug: v8:12161, chromium:1312188
Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983
Auto-Submit: Adam Klein <adamk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79702}
This is a reland of commit e76ad5c6d9
Changes compared to original:
- Move invocation of LAZY_INSTANCE_INITIALIZER to a static global
variable, as some builds were failing with a function-level static.
- Drive-by: Improve documentation a bit.
Original change's description:
> [wasm-gc] Implement isorecursive canonicalization
>
> This implements isorecursive canonicalization for static types.
>
> Not implemented in this CL:
> - Runtime type canonicalization.
> - Cross-module signature canonicalization for purposes of call_indirect.
>
> Bug: v8:7748
> Change-Id: I6214f947444eea8d7b15a29b35c94c3d07ddb525
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541925
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79665}
Bug: v8:7748
Change-Id: I493fba1906491762f7d8bae50108e3e4a743391d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560480
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79692}
Nodes can now hold a LazyDeoptSafepoint which stores the frame state in
case they trigger a lazy deopt. OpProperties have a new CanLazyDeopt
bit, and codegen emits a safepoint table entry + lazy deopt for all
nodes with this bit. Also, we now check the deoptimized code bit on
entry into the maglev compiled function.
An example use of these lazy deopts is added as a PropertyCell fast path
for LdaGlobal, which adds a code dependency on the property cell.
Bug: v8:7700
Change-Id: I663db38dfa7325d38fc6d5f079d263a958074e36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557251
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79688}
This CL adds basic support behind --concurrent-osr,
disabled by default.
When enabled:
1) the first OSR request starts a concurrent OSR compile job.
2) on completion, the code object is inserted into the OSR cache.
3) the next OSR request picks up the cached code (assuming the request
came from the same JumpLoop bytecode).
We add a new osr optimization marker on the feedback vector to
track whether an OSR compile is currently in progress.
One fundamental issue remains: step 3) above is not guaranteed to
hit the same JumpLoop, and a mismatch means the OSR'd code cannot
be installed. This will be addressed in a followup by targeting
specific bytecode offsets for the install request.
This change is based on fanchen.kong@intel.com's earlier
change crrev.com/c/3369361, thank you!
Bug: v8:12161
Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79685}
