It doesn't test anything new, just as a minimal test case to debug if
all wasm deopts tests fail.
This might also be helpful for anybody (including me) having to port
the deoptimization entry to other platforms than the already
implemented x64 builtin.
Bug: 42204618
Change-Id: I97f1da3e6723c107579211921f9473a22c0cf3e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5623151
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94392}
Deleting the cached feedback can cause races with background
compilation jobs that require this feedback to be present.
Instead we only mark it as outdated. There is still a race where an
enqueued background compilation job can read the feedback after the
deopt but before the cached feedback was updated. However, in this case
it only wastes a background compilation that will likely be running into
the deopt again.
In most cases there won't be other compile jobs for the deopted
functions enqueued or they will not be processed before the main thread
reached the TriggerTierUp call in CallRefIC which will then get an
exclusive lock and reprocess the feedback.
This CL also disables --jit-fuzzing in most deopt test cases as they
check assertFalse(%IsTurboFanFunction(wasm.main)) after the deopt which
cannot be guaranteed in this mode.
Fixed: 345403263
Bug: 42204618
Change-Id: Ice7fed0fc6c4d8f60b3e82f4edf0e43245aa6d4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5604483
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94298}
This will give us some more time of liftoff execution to collect
valuable feedback and reduce the risk of additional deopts.
It also fixes flakes in test cases as the unpredictable tiering budget
makes it harder to write stable tests / assert the current tier after
a deopt.
Fixed: 344849329
Bug: 42204618
Change-Id: Id478b23671d41c787e2e80d49cb0ddd73bc79043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5600265
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94262}
The mjsunit mode generated some invalid expressions like
let ...wasmUnsignedLeb($func130) = builder.addFunction(...);
where just the JS variable name should be printed ("$func130").
In general we have to differentiate between 3 cases:
- the variable name, e.g. for the `let $table130 = ...`
- the index, e.g. the third argument in
`builder.addExportOfKind($table130, kExternalTable, $table130.index)`
- the index in LEB, e.g. the second and third value in
`kExprCallIndirect, $sig25, ...wasmUnsignedLeb($table130.index)`
Change-Id: I847773fe274f27a7a27c60c4e70dca91af9932be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5589246
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94256}
Not sure how we (I) missed this. This probably doesn't change much in
terms of performance, still this was done properly by Turbofan while
Turboshaft just "forgets" all the static type information on array.get
without this change.
Bug: 42204049
Change-Id: I19975293fde6bf5cc8914af2fba6702ce89ec8a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5589244
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94181}
This reverts commit 239f4e587f.
Reason for revert: Failures on TSAN bots:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8746694747325887153/+/u/Check/ConcurrentAllocationInLargeSpace
Original change's description:
> [heap][handles] Revise parking invariants for direct handles
>
> Until now, when parking a background thread, a DCHECK would fail if
> the thread's stack contained direct handles, practically allowing
> only limited use of direct handles in background threads. With
> https://crrev.com/c/5331543, the stacks of parked background threads
> are correctly scanned (in builds with conservative stack scanning
> enabled) and therefore this restriction can now be eliminated.
>
> This CL:
>
> - allows unrestricted use of direct handles in background threads;
> - revises the methods and scopes for parking threads, to make sure
> that the trampoline is entered every time a thread is parked and
> the stack marker is set and reset appropriately;
> - disallows explicit use of ParkedScope; and
> - updates tests that used the previous logic.
>
> Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
>
> Bug: 41480448
> Bug: 42203211
> Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5563331
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#94134}
Bug: 41480448
Bug: 42203211
Change-Id: I785f56d0af6e3bcfe08547081db718b2ba21032f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5575089
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94138}
This requires passing information to liftoff if the location for which
we request the LiftoffFrameDescriptionForDeopt for call_ref is actually
about a deopt point (i.e. at the beginning of the call_ref instruction
and therefore prior to the call or about an inlined location in which
case it is about the location at the call / directly after the call.
Bug: 42204618
Change-Id: Ibca128fc307049072bda5a0491780790275e8967
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5558965
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94058}
This enables the wasm-into-wasm inlining by default for non wasm-gc
modules (for wasm-gc modules it has already been enabled by default
since launching wasm-gc).
Also use atomic accesses to `WasmModule::num_small_functions` which is
read by background compilation jobs.
Bug: 40898108
Change-Id: Id4b34aea6b63e3b67d9dd9a1c19230f400c40071
Fixed: 341971943
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5562486
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94055}
Pseudo code example:
function a(target) {
return_call b(target);
}
function b(target) {
call_ref(target)();
}
function c() {}
function d() {}
In this case we might have type feedback for b that target == c.
When we optimize a, we inline b and speculatively inline c with a
deoptIfNot(target == c).
Now, if we call a(d), even though a is the optimized function with the
"wrong" speculation, we only construct an unoptimized output frame for
b, but not for a, as the return_call has already happened.
We still need to "throw away" the optimized code for a though as it
contains the mis-speculation.
Bug: 42204618
Change-Id: I6b6a9de6b47b97cefee610e273b63f1048e27d41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5554494
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94024}
- fix using the wrong parameter stack slot count in case of inlined
frames
- zero out the intermediate parameter stack slots to support GC runs
on the deoptimized frames
- fix the frame slot calculation for the trusted instance in case of
inlined frames
- fix the calculation of caller_frame_top_ in case of inlined frames
with different parameter counts
- fix the feedback vector lookup in case of imported functions
- fix the smi tagging of the frame type marker on non-pointer-
compressed builds: The tagging always performs a left shift by 1
while the smi tagging shifts by 32...
Bug: 42204618
Change-Id: I9bfc15504a674d9a84e9846942614fa4be623ee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5545239
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94003}
The trusted instance is stored at a known location in the optimized
stack frame, so we don't need to waste any bytes on storing extra
deopt data for it.
Bug: 42204618
Change-Id: I872cc686668dfce94ae4eaf0697954a99c5b03ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5543928
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93973}
Differently to JavaScript in Wasm optimized and unoptimized frames have
the same frame type marker, so this check should indeed hold true even
in case of deopts.
Bug: 42204618
Change-Id: I99c9bf20625c425b0636dee630d855bd50b93f9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5543926
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93971}
This adds some basic implementation for having inlined frames at the
deopt point. This requires mapping the one "input" / optimized frame to
multiple output liftoff frames.
The test cases do not cover the intricacies of parameter stack slots,
preserving the correct values of stack slots in general and also only
provides an implementation for inlining at call_direct, while all tail
call variants as well as call_ref and call_indirect are not implemented
yet.
Bug: 42204618
Change-Id: I4ccc18767c6ebad1df96dae6477680abc1b07771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5538057
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93970}
The fuzzer still creates coverage for larger array.new_fixed for
defaultable element types for which the fuzzer can always generate an
easy struct.new_default.
Fixed: 340651309
Change-Id: I49b84374f80adc79a6eadeae137514dbcfa276fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5544137
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93946}
The previous implementation used wasm::value_kind_size() to determine
the size of the liftoff stack slot. This doesn't work for reference
types as value_kind_size() is 4 (e.g. when stored in an object) but the
stack slot stores the uncompressed pointer (meaning kSystemPointerSize
on 64 bit systems).
Also update `TODO(14667)` to `TODO(42204618)` due to updated bug
numbers after the issue tracker migration.
Bug: 42204618
Change-Id: I5501947748132167d704f0e5810ed84f8fda8bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518456
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93922}
Attention: This CL changes how JavaScript handles double registers!
This CL adds support for Simd128 values in the deoptimizer for wasm.
Note that wasm deoptimizations are WIP and the current state is only
implemented for x64.
However, to support Simd128, the deoptimizer needs to know about
Simd128 register values which overlap with double register values.
So we need to migrate double register value handling to use Simd128
registers instead (meaning the 128 bit registers instead of the 64 bit
variants).
For JavaScript, this means that we need to move twice the amount of
data for the double registers. In most cases: Push the value from the
register to the stack, then copy it from the stack to the input
FrameDescription, copy it from the FrameDescription to the
TranslatedValue, from there into the outgoing FrameDescription and
finally from there back into the register (if it's still in a register
that is).
Bug: 42204618
Change-Id: I7253d037460a095f893cea239d448b1977007d41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5513446
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93911}
Besides an implementation error causing an out-of-bounds array access
if the last known polymorphic / monomorphic call target is not inlined,
having a deopt node on the slow path could cause deopt loops.
Fixed: 339115607
Bug: 42204618
Change-Id: I0da7ef9c8a0403a2f972d740a3ae081e6da4a926
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518892
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93761}
This adds support for deopting a function that has parameters passed
via stack slots.
This requires the deoptimizer to include the parameter stack slots
into the FrameDescription which also requires to include the stack
objects between the frame and the parameter slots (2 slots) and then
to "copy" this over to the output FrameDescription.
Bug: 42204618
Change-Id: I74884ca77a4817ccb7b0f7319bd81fdb9014b5a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5498887
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93741}
Wasm doesn't have a JS closure, nor does it have a context.
Use a __ SmiConstant(0) as dummy value to keep the overhead as small as
possible.
Bug: 42204618
Change-Id: I1071827d132dc9962958b9b21d95721a0377511a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518453
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93738}
Also make the constructor private.
The FrameDescriptor class accesses (both read&write) memory outside of
its object assuming that additional memory was allocated for the
parameters. This implementation detail shouldn't leak outside of the
class itself.
Bug: 42204618
Change-Id: Iad691b6d4d5a9731eaacc9e34f632769b5a14061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5492422
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93724}
This CL adds support for literals (i.e. values that are constants in
the optimizing compiler) to the wasm deoptimization.
The supported types are i32, i64, f32, f64, i31ref.
Bug: 42204618
Change-Id: Id40ca62d79be805acfcd22f01c91f4645bc8ac98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5501046
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93723}
This CL adds a first version of deopt support for WebAssembly
supporting the included test case. Many basic features are still
missing like:
- parameters that are passed on the stack and not as registers
- literals
- floating point registers
- inlined deopt point (requires multiple output frames)
- S128 values (SIMD)
Bug: 42204618
Change-Id: Idac1c3ed17fad9250ca6ed7958f870347e1fbc1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5467825
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93604}
This allows access to these constants outside of lifotff, e.g. by the
deoptimizer who also needs to "understand" the liftoff frame layout.
Bug: 42204618
Change-Id: If9ee5fc89d41046e9d97e4f67569a8ff465dfbbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5473606
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93540}
By always picking the first memory to decide on the integer type of
memory.size, we might either wrongly explicitly truncate it and
implicitly extend it or wrongly explicitly extend it to then
implicitly truncate it.
In either case, Turbofan does not seem care about these type
differences and the value can never be larger than int32 max, so this
is just an inconsistency.
Bug: 42204191
Change-Id: Ib04a8dccb0f0faa63930211136f0b5acf3ed89a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5472109
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93508}
The wasm stack values were pushed in the "wrong" order (i.e. not
consistent with the order of the VarStates in liftoff.
There was also a mistake on the count of locals.
The correct calculation is:
- values on the value stack `decoder->stack_size()`
- wasm function locals `ssa_env_.size() - param_count`
Unfortunately, the decoder value stack already describes the state
after the call_ref instruction, so we need to adapt the following:
- add the call_ref callee
- add the wasm trusted instance (implicit argument to the call_ref)
- add the call's explicit arguments
- subtract the call's results (as these are pushed after the call)
Drive-by change: Include deopt data size in WasmCode to wasm memory
usage estimation.
Bug: 42204618
Change-Id: Ic460f47b27dcfdaaa2054bcebcb4f7eae72d19bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5468102
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93475}
Liftoff has to collect the frame descriptions for the deopt points so
that the deoptimizer can rebuild the full liftoff frame.
Bug: 42204618
Change-Id: Icf8427516b9303f259e4650b89914b1b7f0d79f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5467813
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93472}
This CL moves the VarState out of the liftoff assembler.
VarState describes the location of a wasm variable (like a value on the
wasm value stack, a local or a parameter) and defines its "physical"
location (i.e. a register, a stack slot or a constant).
This information is needed by the deoptimizer to be able to construct a
Liftoff frame as, differently to unoptimized JS frames, the wasm frame
layout depends on internal liftoff details like register allocation.
Bug: 42204618
Change-Id: I5b55459541fd54796bcb4bbab0ef854fefbda27f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5463596
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93466}
This CL adds the generation of wasm deopt data as part of Turboshaft
code generation and adds the serialized metadata to the WasmCode
object.
The deopt data includes:
- deopt exits (mapping from PC offset to wire bytes offset and
translation index)
- translations (data about the inputs to the FrameState and their
locations, e.g. register, stack offset, literal)
- literals (literal values used within the translations)
Bug: v8:14667
Change-Id: I6ac03df929d25bc632af44f56a170179632630ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5447118
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93427}
Liftoff has multiple soft bailouts for trying to generate SIMD
instructions when the hardware does not support SIMD natively.
These cases are not supported by V8 at all and are already rejected by
the decoder, so liftoff can just rely on that.
Change-Id: I3e5ad4892e8579b5b4dd5e13c32a1b3e12fbc9f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5454311
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93387}
The DeoptimizationFrameTranslation::Iterator requires the byte array to
be allocated on the heap. As wasm is isolate-independent, it cannot
have this data on the heap and it cannot create a "heapified" copy on
demand (as it isn't safe to allocate on the heap during frame
translation).
This CL moves the implementation of the iterator to a class taking a
raw byte vector. For JS, the original class is a trivial wrapper around
this implementation.
Bug: v8:14667
Change-Id: Ic8bcbe3466914c725e5d6b638d91052be82b37d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5443269
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93337}
This CL adds a new FramestateType::kkWasmLiftoffFunction and the
corresponding TranslatedFrame::kWasmLiftoffFunction and
TranslationOpcode::WASM_LIFTOFF_FRAME.
Bug: v8:14667
Change-Id: I767bc06adccfe9b9f233a083f1e0dcdf11aa8ca3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5433057
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93287}
Wasm doesn't yet have deopt support, so this mode would only uncover
the deoptimizer crashing.
To support this flag, once wasm supports deopts, it will need to work
in an isolate-independent way in wasm.
Fixed: v8:14706
Change-Id: Id4a4a0fb0e879e0f3a747fd11f2a0202e7a832ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5434036
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93220}
This CL adds a new feature flag --wasm-deopt, an experimental feature
to allow the optimizing compiler to emit deopts in the wasm pipeline
and for the runtime to support deopting wasm functions to their
baseline (liftoff) variant.
In a first version this will be built to deopt if the call target of a
call_ref instruction is mispredicted.
This first CL adds the code to emit a DeoptIf node and the FrameState
required to be able to build the corresponding unoptimized stack frame.
Bug: v8:14667
Change-Id: I2f61fa45725934b55779de4c991420c4307b60a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5421109
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93194}
Calling the memory representation input_rep is somewhat misleading
given that the input into the rmw isn't the memory but the register
representation.
The input register representation (i.e. the value to be written) is
the same representation as the result representation, so it is renamed
to in_out_rep.
Change-Id: I49764f093d6366e5e45a75fbd975e3136e6a3d7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5385340
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93067}
It would be nice to not have implicit truncations from Word64 to
Word32 in Turboshaft as they are inconsistently sometimes explicit and
sometimes implicit.
However, as the same was true for Turbofan it is difficult to enforce
it on Turboshaft graphs created from Turbofan.
To have this asserted in Turboshaft-only cases (wasm, unittests,
Maglev->Turboshaft), pass this information downwards and relax the
assertion again in ValidOpInputRep.
Note: The implicit truncation was disallowed in
https://crrev.com/c/5380531 .
Fixed: 330638812
Change-Id: Id67d5781dfac88fd37131c0f49eb3fafa6cdcf0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5385337
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93022}
kWasmAnyRef is a negative integer and the module builder expects
positive integers in the function body, therefore kAnyRefCode should
be used instead.
Change-Id: I0319b41a5b981d5e4fa26bff01f5f75ef014f965
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5387890
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Eva Herencsárová <evih@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93006}
ref.test, ref.cast, br_on_cast, br_on_cast_fail allow arbitrary heap
types, so they also allow exnref and noexnref.
This CL also fixes the missing type checks in the js to wasm wrapper.
Bug: v8:14398
Change-Id: Ieefb9a8e99d3d7a4b175db60f55b7fa9a96c5203
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5372489
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92867}
AddCode() is only called for wrappers, so the inlining_positions
is always empty. Still, as all use the WasmCompilationResult, it's just
as easy to pass through the vector from the compilation result as to
create a dummy vector.
Change-Id: I3288c4239d3d9788664434b92186349520845b07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5367023
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92799}
The space results in the following warning on `git cl upload`:
v8/src/maglev/maglev-graph-builder.cc:9288:
(cpplint) Missing username in TODO; it should look like
"// TODO(my_username): Stuff." [readability/todo] [2]
Change-Id: I30467c6fcda8650487a7e44a555b04355bef14e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5361877
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92774}
I just ran into a file complaining about not knowing what
V8_FALLTHROUGH is. I don't think there is any benefit for this macro
any more and we should move to using `[[fallthrough]]` instead.
As a first step, just changing what the macro does so that the change
and the renaming can be done in two steps to avoid reverts in case of
unforeseen issues.
Change-Id: I29186124fba3e7f6fb581c3c70fd39abb08e1291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5361456
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92754}
ref.i31 in the constant expression evaluator:
static_cast<intptr_t>(i32_val << 2) >> 1
As intptr_t is 32 bits as well, this loses a bit of information.
Fixed: 328499555
Change-Id: Ic60bae8b8a3c06633906905bdbd6d892c94ffd11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5351806
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92719}
Matthias Liedtke