This commit allows using unaligned load/store, which is more efficient
for 2 bytes,4 bytes and 8 bytes memory access.
Use RISCV_HAS_NO_UNALIGNED to control whether enable the fast path or not.
Change-Id: I1d321e6e5fa5bc31541c8dbfe582881d80743483
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329803
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#78427}
Straight-line bytecode with exactly one "next" bytecode (i.e. everything
that can't affect control flow) will always have the same "out" liveness
as the next bytecode's "in" liveness. For those cases, we can save a bit
of time and memory by aliasing the pointers between the bytecode's out
liveness and the next bytecode's in liveness, and skipping copying
between them.
This is done by specializing the current liveness update on whether this
is the first pass (which will allocate and initialize the liveness
bitvectors) or an update pass (which will revisit loops to collect
liveness crossing over the back-edge, and propagate this liveness
through the loop bodies). On the first pass, we can delay allocation of
the out liveness until we know it needs to be union of multiple in
livenesses, and on the update pass we can skip it if it is an alias.
As a drive-by, tweak BitVector::CopyFrom to require copying from a
vector with the same size (same as Union or Intersect), and move the
only different sized vector use (in Resize) to be inline.
Change-Id: Iad1b2e1b927a37ad925ef68e2a224152aaa2ba18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350452
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78425}
Shared array buffers are not tracked by the garbage collector, which
makes the fuzzer run out of memory pretty quickly. Since shared memory
is not needed any more for testing atomics, we can just make the memory
non-shared again.
This also improves the performance of the fuzzer (execs/s) by more than
2x locally.
R=ahaas@chromium.org
Bug: chromium:1281419
Change-Id: Ic7803617d6a14aaa698d9181327ec20b21d29faa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350764
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78418}
The motivation is being able to build Chrome/Mac/Intel on an
Apple Silicon mac.
Depends on https://chromium-review.googlesource.com/c/chromium/src/+/3348020
- Correctly set v8_snapshot_toolchain when targeting x64 on an arm64
host (always use the clang_ toolchain for now since that's all
that's needed at the moment)
- Check V8_HOST_ARCH in immediate-crash.h. In V8 terminology, "host"
is the machine the snapshot generation runs on, while "target" is the
machine that V8 runs on when it JITs. IMMEDIATE_CRASH runs on the
host. Up to now, target arch x64 implied host arch x64 so the old code
happened to work too, but this is the correct macro (and it makes this
cross scenario work).
- In assembler-x64.cc, only compile the code that probes the current CPU
when running on an intel host. (There's an early return for snapshot
generation anyways.)
Bug: chromium:1280968
Change-Id: I4821a5994de8ed5f9e4f62184dc6ab6f5223bc3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3348040
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78417}
Report young generation GC statistics to the Recorder API.
These will be used by Blink to populate UMA histograms.
Existing UMA reporting in V8 remains as is for now and will be removed
in a followup.
With this CL, minor mark-compaction statistics are reported as part
of V8.GC.Cycle.*.Young. Also V8.GCScavengeReason is migrated to
V8.GC.Cycle.Reason.Young.
This CL goes together with:
https://chromium-review.googlesource.com/c/chromium/src/+/3320388
Bug: chromium:1154636
Change-Id: Ia1030c80d4bc75ac6e176ed60f838929ddb9b20f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320430
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78416}
We clear the worker state in the worker thread after processing
all messages (and getting the terminate signal). This could cause
a race condition when interacting with the worker from the main thread.
This was previously working and broke with https://crrev.com/c/3318669
- Add is_joined_ variable which is mutex guarded
- Simplify Worker::State
- Mutex guard task_runner_ access
Bug: v8:12487
Change-Id: Ib53e5a1a636cb29db50efdb63526b0023a5ea768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345005
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78415}
Without simple FP aliasing, a SIMD register will overlap with two
floating-point registers. If we spill an FP register to use it for a
SIMD operation, we need to make sure to also spill the "sibling" FP
register.
R=leszeks@chromium.org
Bug: v8:12330, chromium:1271244
Change-Id: I7fdc6cb8da35d66b4862a8a913ba4ff906cf05aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347576
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78414}
Initialize the (thread-local) memory protection key permissions for any
isolate that joins the wasm engine. Otherwise it can happen that an
isolate gets Wasm code from the cache without ever compiling anything
(hence without ever changing memory protection key permissions), and
then it would not be allowed to access (read or execute) the code.
I tested this change manually on a PKU-enabled devices. The new test
crashed before the fix, and completes successfully afterwards.
R=ahaas@chromium.org
Bug: v8:11974, chromium:1280451
Change-Id: I90dded8b4fdaa8cf34b44107291d3f525ce16335
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347563
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78413}
After https://crrev.com/c/3315446 we allocate the memory protection key
unconditionally, so the method is redundant.
R=ahaas@chromium.org
Bug: v8:11974
Change-Id: I205a0cda86dfaf394c68788a662241d76a3f8510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347562
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78412}
The mid-tier register allocator could not handle the case that the same
virtual register was used for
- the input corresponding to the 'same-as-input' output, and
- another 'unique register' input.
In this case, it cannot choose the already assigned register for the
'unique' register. Instead, it needs to allocate a new register and
introduce a gap move to duplicate the input value in two different
registers.
FYI, the instruction where the current logic failed was:
(v5(0), v6(R)) = IA32AddPair v7(R) v7(*) v8(R) v7(R)
(where the last input was marked 'unique').
R=leszeks@chromium.orgCC=thibaudm@chromium.org
Bug: v8:12330, chromium:1272204
Change-Id: Ie4843aa9f5e027afe503e0481a4acdfa325dfe0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347821
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78411}
If a name is defined for a wasm function, we retrieve it from the module
and use it for tracing.
Change-Id: I42da12d2476af573017daaa3f216cca8a95efbbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344646
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78409}
Avoid the trailing ";" after the last parallel gap move. Instead, make the
semicolon part of the delimiter between moves.
Before:
gap ([stack:8|w32] = [constant:0];) ([edi|R|w32] = [constant:7]; [edx|R|w32] = [constant:8];)
After:
gap ([stack:8|w32] = [constant:0]) ([edi|R|w32] = [constant:7]; [edx|R|w32] = [constant:8])
R=mslekova@chromium.org
Bug: v8:12330
Change-Id: If9f3d67f09e48f717e839fa7fb8968f20bb58b16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347820
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78407}
A SIMD register can "block" more than one FP register. In that case, no
virtual register will be assigned for one of the FP registers. This is
fine, we just need to detect and handle that case correctly.
R=thibaudm@chromium.org
CC=leszeks@chromium.org
Bug: chromium:1271538, v8:12330
Change-Id: I7ec19229445c5ace0782f63945acb89322816540
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293082
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78400}
This bitset is used to quickly find the set of used / free registers,
and it should always be consistent with the information in the
{RegisterState}.
This CL adds a little validation after the register allocation of each
instruction.
This should help fuzzers to catch inconsistencies earlier.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: Ia8da9708e982726d72d156f5bca04213a3f03b7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3341520
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78398}
This reverts commit 00a757fabd.
Reason for revert: Caused perf regressions, https://crbug.com/1280236
Original change's description:
> Shorten generated code for binary-search switches
>
> On some branches of the search tree for a binary-search switch, the
> input value is sufficiently constrained that we could unconditionally
> jump to the last possible case rather than checking for value equality.
> This shortens some builtins by a few instructions and might speed things
> up, though I expect the effect to be small.
>
> Change-Id: I2313f26976e6d3c182f03bd927b338c8175b3af3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3335437
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#78376}
Bug: chromium:1280236
Change-Id: I88d9ff64641b85d48198b7012df2eeb9441913b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3343234
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78397}
We switch the order of inlining and loop unrolling optimizations. This
gives small improvements to wasm-gc benchmarks.
Changes:
- Change the loop analysis algorithm to accept loops directly connected
to the graph's end. This is required because some nodes in an inlined
function, such as tail calls, might be directly connected to the outer
function's end without an intervening LoopExit node.
- Based on the above, skip emitting loop exits for some Throw nodes in
WasmGraphBuildingInterface.
- Introduce WasmInliningPhase, add it before loop unrolling. Remove
inlining from WasmOptimizationPhase.
- Handle graph terminators in loop unrolling.
- Add loops in the inlined function to the callers loop_infos.
Drive-by:
- Allow more wasm builtins in unrolled loops.
- Reduce inlining parameters to reflect that functions are now slightly
smaller during inlining, as no unrolling has taken place yet.
Bug: v8:12166
Change-Id: Iadd6b2f75170aa153ca1efb47fbb0d185c2b8371
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329783
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78394}
... in order to avoid Code <-> CodeT conversions in builtins.
This CL changes the meaning of RelocInfo::CODE_TARGET which now expects
CodeT objects as a code target.
In order to reduce code churn this CL makes BUILTIN_CODE and friends
return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and
friends will be removed.
Bug: v8:11880
Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78393}
This is the first step towards moving away from sending `url` with every
call frame when emitting the `Debugger.paused` event.
Bug: chromium:1270316, chromium:1271078
Change-Id: I2f57f21e15bf908ffb53f5c7b5862d3efa329c86
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344946
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78392}
In the WebAssembly Turbofan pipeline, inlining should come before
unrolling. When we inline a function, we link unhandled throwing calls
in it to the handler of the caller node. If a throwing call is in a
loop, we need to generate loop exits between the call and the handler if
we want to unroll later.
This CL adds dangling IfException/LoopExit nodes following each throwing
call in an inlined function. These nodes are connected as required in
inlining.
Drive-by: Remove CheckForException from tail calls, which are kNoThrow.
Bug: v8:12166
Change-Id: Icb8371a0a27234f07d4880e5b3005fc90a91a4b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322975
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78391}
Since load elimination is only enabled for wasm-gc, we should use
LoadImmutable over LoadImmutableFromObject when possible. This is
possible for instance fields, which are always populated before the
start of function execution.
Bug: v8:11510, chromium:1279211
Change-Id: Ib11e8d19b91a16f509983378f74bdc4c3c2150ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3341522
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78390}
While there, make sure to exit on failures (e.g. missing tools).
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Ie84425bbedefc8c37cf12afbf0ad541caa125ac0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333634
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78388}
When compiled with gn argument 'is_debug=false' these tests fail on
Windows due to the fact that they're compiled with '/guard:cf'.
This CL changes the use of FUNCTION_CAST to GeneratedCode::Call which
contains DISABLE_CFI_ICALL attribute. This is analogous to how
assembled functions are called in Assembler tests for other
architectures.
Change-Id: I330e29a508ad1421cb98dea3d9761f05272ab763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3341511
Auto-Submit: Dmitrii Tsykunov <dtsykunov1@yandex-team.ru>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78386}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
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/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
This is the final change list in the list of refactorings to split off
the implementations of v8::StackFrame and CallSite objects (as used by
the V8 JavaScript stack API). See https://bit.ly/v8-stack-frame for the
whole story.
This CL adds the v8::internal::StackFrameInfo class as new backing
implementation of v8::StackFrame, and puts it into debug-objects.tq
to indicate that it's used for the debugger API only. This new class
is lightweight and only holds on to static information about the
stack frame, and is thus usable for the V8 inspector to implement
async stack traces in a cheaper manner going forward.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278650
Fixed: chromium:1278647
Change-Id: I4dbf2d850f47797263af225895129499169aad02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302794
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78382}
