Also remove useless comment in test-assembler-riscv64
Change-Id: I28451386449f15542b02383d8bf1aa9c4539469c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669660
Auto-Submit: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#80768}
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}
This CL adds a check to all integer/and fp load/store operations,
if the offset fits in an `is_int16` and if alignment requirements
are met (specific to lwa, ld and std) then a non prefixed load/store
instruction will be used.
Note that operation mode (MRI vs MRR) gets set during instruction selection.
Change-Id: I68e2aa1d559c7ff058d715e6e577a14b590b632b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669186
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80765}
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}
This lets us accept spec-compliant CBOR tag for message envelopes.
This also includes a change in v8-inspector-session-impl.cc that
relaxes an envelope check to allow spec-compliant envelopes.
Change-Id: Id77c1e0fc4b62d78e8580f81ef38d50e3eb54a1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3662540
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80761}
Initialization after reset + unnecessary use of handle scope appear to
be the culprit here. Most of the other functions in debug::Script do not
use HandleScope, so this reconciles these differences. Additionally,
the call to obtain and initialize the hash within
ActualScript::Initialize was inconsistent: all of the other fields were
initialized prior to resetting the script and source.
These reconciliations appear to fix this crash.
Bug: chromium:1325036
Change-Id: Ia86e83b6c99955a3ac80a4a8845c0df0172e991c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3648082
Commit-Queue: Robert Paveza <Rob.Paveza@microsoft.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80760}
IsCompiledScope retains code to be safe against bytecode flushing, but
%PrepareFunctionForOptimization isn't currently initializing it with the
function's current compiled state. IOW, it's only retaining freshly
compiled code and is causing flakes for already-compiled functions.
Bug: v8:12697
Change-Id: Ie82a4adb8a136da708b3ae0ce27a42f5c277d324
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668318
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80756}
Port 22a16bda86
Original Commit Message:
The Runtime_WasmCompileLazy function was returning a ptr-sized address,
wrapped in an Object. This worked because no GC is triggered between the
return from the runtime function and the point where we jump to the
returned address.
In a pointer-compressed world though, generated code assumes that all
objects live in the same 4GB heap, so comparisons only compare the lower
32 bit. On a 64-bit system, this can lead to collisions where a
comparison determines that the returned address equals a heap object,
even though the upper 32-bit differ.
This happens occasionally in the wild, where the returned function entry
pointer has the same lower half than the exception sentinel value. This
leads to triggering stack unwinding (by the CEntry stub), which then
fails (with a CHECK) because there is no pending exception.
This CL fixes that by returning a Smi instead which is the offset in the
jump table where the kWasmCompileLazy builtin should jump to. The
builtin then gets the jump table start address from the instance object,
adds the offset that the runtime function returned, and performs the
jump.
We do not include a regression test because this failure is very
spurious and hard to reproduce.
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I92907b97a9d44d8cf42bb356ef350a22f7c5d5e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666249
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80752}
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 fast path of all write barriers already got mostly unified in
https://crrev.com/c/3644964. However, the shared heap write barrier
still added a new branch in the fast path of the full write barrier.
This CL unifies the branch for the generational and the shared heap
write barrier in the fast path at the cost of an additional branch in
the slow path. This should hopefully the rest of the regressions caused
by introducing the shared heap write barrier.
Bug: chromium:1326446, v8:11708
Change-Id: Id5a8334c50a7455e53caf65891d4304d9d2e7702
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663091
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80749}
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}
Due to collections with inlined storage, Oilpan still supports on-stack
Members, which are always compressed if pointer compression is enabled.
This CL scans halfwords (together with full words) on stack to find
potential pointers. Since on-heap pointers can only be compressed and
in-construction objects always reside on heap, only halfwords need to be
scanned for them.
The alternative potential followup approaches:
1) Use a separate uncompressed type for pointer in inlined collections;
2) Dynamically register regions of stack containing compressed pointers.
Bug: chromium:1325007
Change-Id: Ia706fd8e7383d30aff11f4014faa9edd3d289a55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644959
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80747}
We introduce wasm-gc specific nodes into the Turbofan IR, corresponding
to the wasm opcodes:
ref.as_non_null, ref.is_null, ref.null, rtt.canon, ref.test, ref.cast.
We define them as simplified operators. These are lowered by a dedicated
phase in the wasm pipeline.
Optimizations based on these nodes will be introduced later.
Note: We rename ObjectReferenceKnowledge to WasmTypeCheckConfig and move
it to a separate file, as it is now used in simplified-operator as well.
Bug: v8:7748
Change-Id: Iceaf04eca089b08bad794f567359196e8ba78d93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654102
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80746}
There is now only one invocation left of
MemoryAllocator::Unmapper::FreeQueuedChunks in the GC epilogue.
Bug: chromium:1329064, chromium:1327132
Change-Id: Icc21ada4c5a8a9505ed6435ef1f62fe48b2dbb52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667079
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80745}
GN is not available as a cipd package for ppc/s390 and
needs to be built from source.
Change-Id: I5f6eda13cd6227d20fc800cab7f54496a2d33f68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663154
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80743}
When a callback does not intercept the request
1) it should not call info.GetReturnValue().Set(),
2) it must not produce side effects.
Bug: v8:12873, chromium:1310062
Change-Id: If02994f24f1a68eb96c1af7cdd6dd7109f0617c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652786
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80742}
This CL fixes an issue with async stacks. The async task stack is not
torn down between page navigations or reloads. The result is that
any new async tasks are stacked on top of the old pages async task
stack.
This was not prominent until now for two reasons:
1) Async tasks created in blink are always finished as long as
destructors have time to run.
2) When V8 is terminated while running the micro task queue also
all async tasks created for Promises (including `await`) are
cleaned up properly.
Introducing the stack tagging API made it more common for having
unfinished async tasks open outside the MTQ, which left the
async task stack non-empty during navigation.
This CL fixes this problem by clearing out all the async task
and async stack data structures for a context group when that
context group is reset.
R=bmeurer@chromium.org, victorporof@chromium.org
Fixed: chromium:1328785
Change-Id: Iee0c3c4a55f66e643829dae3726dc03c735da1dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666620
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80741}
V8_SANDBOX has been renamed to V8_ENABLE_SANDBOX in crrev.com/c/3647355
and its remaining uses in Chromium have now been renamed as well.
Bug: v8:10391
Change-Id: Ibb23ecab6687438b462685ef7fa044c0024dd098
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660251
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80739}
There were multiple fields missing from the output.
R=jkummerow@chromium.org
Change-Id: Ie4c3171339943414c58c2fe6f0e507cdd531dd8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3664497
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80738}
Add a generic DefineNamedOwn node for DefineNamedOwnProperty, and a
monomorphic fast path identical to SetNamedProperty for simple field
stores.
Bug: v8:7700
Change-Id: I35ff9d54be8bb8e437865e4d1ba38eb726034e24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663084
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@{#80736}
This CL fixes a wrong assumption in the LiveEdit machinery. Namely
the assumption that every FunctionLiteral the parser finds, will have
a corresponding SFI created by the compiler. This assumption does not
hold in all cases. Inner functions that are never referenced by the
outer function don't get an SFI.
R=bmeurer@chromium.org
Fixed: chromium:1328453
Change-Id: I674f023f948954c1fcae04a4aa2afb69ea1642aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663443
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80735}
The Runtime_WasmCompileLazy function was returning a ptr-sized address,
wrapped in an Object. This worked because no GC is triggered between the
return from the runtime function and the point where we jump to the
returned address.
In a pointer-compressed world though, generated code assumes that all
objects live in the same 4GB heap, so comparisons only compare the lower
32 bit. On a 64-bit system, this can lead to collisions where a
comparison determines that the returned address equals a heap object,
even though the upper 32-bit differ.
This happens occasionally in the wild, where the returned function entry
pointer has the same lower half than the exception sentinel value. This
leads to triggering stack unwinding (by the CEntry stub), which then
fails (with a CHECK) because there is no pending exception.
This CL fixes that by returning a Smi instead which is the offset in the
jump table where the kWasmCompileLazy builtin should jump to. The
builtin then gets the jump table start address from the instance object,
adds the offset that the runtime function returned, and performs the
jump.
We do not include a regression test because this failure is very
spurious and hard to reproduce.
R=jkummerow@chromium.org
Bug: chromium:1311960
Change-Id: I5a72daf78905904f8ae8ade8630793c42e223984
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663093
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80729}
The Wasm C API currently disabled dynamic tiering, in order to have
deterministic behaviour for serialization of Wasm modules.
As dynamic tiering is now shipped, also the C API should follow.
Serialization of a Wasm module now just serializes the current state, so
embedders are responsible for warming up a module before serializing it.
If requested, we can add an internal API to enforce full tier-up of all
functions, but we will leave that for later.
R=ahaas@chromium.org, jkummerow@chromium.org
Bug: v8:12899
Change-Id: I55df63f0b6c1f285e4983f9f7d5fb66aa41637bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660261
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80727}
Math between disparate enums is deprecated. Use constexprs instead.
This requires switching some caller code to work with the new non-enum
constants also.
Bug: chromium:1284275
Change-Id: Ifb3c8757ed62e2a0966120f830f0a7e282b53a16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3661148
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80722}
We can check map validity cells for Sminess without checking their
value, since their value as a Smi (and not a Cell) should always be
"valid"
Change-Id: Ie73079107144e352c358c0ec42abd0c10bdcf73a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663090
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80721}
Clean up a couple of the StoreHandler methods returning Builtins to
directly return the Code object, so that it can be used as a handler
straight away without having to go via the MakeCodeHandler helper (which
wasn't making anything anymore).
Change-Id: I4976829d25e2bdad0cf41088b76121ac9b500cd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663083
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80720}
