A corrupted sandbox might confuse the type feedback processor
into inlining the wrong function, so the inlining mechanism
should check to make sure the inlining candidate's signature
is compatible with the call.
Bug: 336507783
Change-Id: I5fb99b7894f060a2bcc754349175e2570b5a6045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5621153
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94386}
This ports the recently introduced signature verification from
call_ref to compiled (i.e. non-generic) js-to-wasm wrappers, to
prevent escaping from a corrupted sandbox by calling broken Wasm
functions from JS.
Bug: 336507783
Change-Id: I2946424b39ca345ab6f6d31ad8308327cd5be1e5
Fixed: 336009921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5622490
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94382}
To prevent sandbox escapes, this adds signature verification to each
call_ref / return_call_ref instruction. In-sandbox corruption could
modify funcrefs, but with these checks that cannot lead to tagged vs.
untagged type confusion in the callee.
Since part of the work happens in a builtin, there is no runtime flag
to disable the feature.
Bug: 336507783
Change-Id: Icb463973c3acb3595e920cac453e59303d749b00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5577681
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94267}
When a Phi has an input that's a load of a ProtectedPointer, we must not
choose compressed representation for this Phi, because we can't restore
its uncompressed value by using the heap cage base.
Fixed: 343035068
Change-Id: I9b6c13f446ec254b426fd905d4aa58436cc2ed74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5592473
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94213}
This patch introduces reordering of return values into an untagged
and a tagged block, just like what we already do for parameters.
This is a prerequisite for efficient signature verification: it
allows us to compare the sizes of these blocks, instead of needing
large bit maps to store each return value's taggedness.
Bug: 336507783
Change-Id: Ic6ea16e3fad333068d2e087bb1e9e4ad1f944667
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5580042
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94159}
For some string-related operations, the difference between "kPure"
(=doesn't depend on effects) and "kEliminatable" (=does depend on
effects, hence cannot be rescheduled across control flow) matters.
No regression test because the only repro I know of turns into an
endless loop when the bug is fixed.
Fixed: 342197919
Change-Id: Id57771e3bbdf0c4e432b21effb31fb2a2e983262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5569137
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94096}
Liftoff register allocation needs to be more careful to avoid
aliasing, considering the complexity of the assembler backend
implementations for this operation.
Fixed: 341947685
Change-Id: Ia0369311c4c49735ab163c57998dc04cd71d0a40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5563329
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94068}
to avoid GN warnings about unrecognized options.
Also restore the functionality to migrate `use_goma` to `use_remoteexec`,
which was recently dropped accidentally.
No-Try: true
Change-Id: I32ef14d419d8f958062b109d0f476701d678f35d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5544140
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93951}
String.fromCharCode silently masks the char_code value to 16 bits
before creating a string. Maglev was our only compiler that didn't
apply this mask *before* checking whether the value is in range for
cached one-byte strings, which caused it to e.g. return a freshly
allocated two-byte string for the input value 0x10000.
This was flushed out by Factory::NewCopiedSubstring making a slightly
brittle assumption that two-byte strings have underlying two-byte
FlatContents. This patch makes that code more robust as well.
Fixed: 339681888
Change-Id: If37f86d8f12c4a7286629ab1404577858435c605
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5538158
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93948}
Two functions were unused, two were almost duplicates of each other,
and the recently introduced ProtectedPointer representation was
handled a bit inconsistently.
This patch isn't expected to change any observable behavior.
Bug: 42202729
Change-Id: Ia5c46b7503f4d2bdcceff3fbe92d9592895d7579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5529247
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93916}
Replacing the WasmExportedFunctionData's pointer to an on-heap
WasmInstanceObject with a protected pointer to the corresponding
WasmTrustedInstanceData eliminates an easy way for in-sandbox
corruption to affect the coupling between these two objects.
Bug: 336507783
Change-Id: Iec3ce21ab5b39479a0413e72f77079595f1a69a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5535193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93894}
Giving the WasmTrustedInstanceData a trustworthy way to retrieve the
associated NativeModule (whereas the existing multi-hop pointer path
to it required going through potentially-corrupted heap objects).
Bug: 336507783
Change-Id: Iff2247d63f2f0668ac658198bbf0fd499836f7f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5529236
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93831}
To avoid any confusion around VRP eligibility.
We currently have no plans to ship this feature, and don't care
to see it used as a load-bearing building block of submitted bug
reports.
Change-Id: I17b8c0f5b70d0c26747ba2750a51ff35c2618e50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518455
Commit-Queue: Andreas Haas <ahaas@chromium.org>
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@{#93740}
When block types refer to nonexistent signature indices, just print
that raw index, rather than trying to get a name for it.
Bonus change: speed up a quadratically slow DCHECK in Turboshaft.
Fixed: 338071688
Change-Id: I0009f9f58c590fe99f20ba6a3fd858cae1bcccb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5510483
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93685}
In-sandbox corruption could cause i64 values to be passed to
functions expecting an i32. This patch unconditionally zeros
the high word of i32 register parameters to prevent that.
Bug: 334120897
Change-Id: Ia19925e5133b6c560ca8308fd84ae64ff0208b86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5494364
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93680}
When processing empty names of imports/exports, the code currently
ends up doing `memcpy(nullptr, ..., 0)`, which is Undefined Behavior
because the `dst` argument must be non-nullptr (even when the length
is zero).
Fixed: 337141854
Change-Id: Iaff83fa71bd8cbe4ab9690f4bf0f29750291284c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5496964
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93644}
This moves the WasmFunctionData object hierarchy to trusted space,
which addresses some of the ways how Wasm functions can currently
be used for escaping from a compromised V8 sandbox.
Bug: 334120897
Change-Id: I23aa5bc7b1205ff29d0b6dac6fe301494275565e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5484107
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93633}
The spec wants two i32 values, Turboshaft expects two i32 values,
the builtin should return two i32 values, CSA can be taught to
support two i32 values.
Fixed: 336007398
Change-Id: I29c1821ec6e54fc55df794f7122a549633575dc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5478967
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93561}
The previous in-between state where views were supertypes of 'none'
but not subtypes of 'any' was too inconsistent to be workable. This
patch forces the three view types to be non-nullable references,
which effectively puts them into single-occupant type hierarchies
of their own.
Fixed: 335640704
Bug: 42202811
Change-Id: I58f9a590c85bf90023d2b0bcdf1b1fbd071cda99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5471674
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93534}
We get a {tag} parameter, so use it, don't discard it.
Test coverage will be provided by crrev.com/c/5465514, whose
currently-failing try jobs should be fixed by this.
Bug: 42204510
Change-Id: I053257e1b5546b80d2b1b3e4aa565d85085498f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5467824
Reviewed-by: Eric Leese <leese@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eric Leese <leese@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93476}
This switches the disassembly format shown in Turbolizer from
"mjsunit"/kExprFoo syntax to wat syntax.
The motivation is to be able to remove the disassembler that
emits the former format; whereas we need the wat disassembler
for DevTools anyway.
Change-Id: I2d7d382441bbf1e6b1d60ddf3299bf2800e48fb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5463120
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93432}
This CL changes the implementation of the --wasm-fuzzer-gen-test
flag to the new and improved implementation that was recently
introduced for wami's --mjsunit output mode.
As a side effect, this lets us drop the "populate explicit recgroups"
support from the module decoder.
Change-Id: Ia3ab79131e1b62be6a9f1a6760fbd6f96a389229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5458515
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93419}
The memory-accessing stringref instructions:
- string.new_{utf8,lossy_utf8,wtf8}
- string.new_wtf16
- string.encode_{utf8,lossy_utf8,wtf8}
- string.encode_wtf16
- stringview_wtf8.encode_{utf8,lossy_utf8,wtf8}
- stringview_wtf16.encode
were not yet prepared to access 64-bit memories, or memories with
an index other than zero. This patch adds the missing support.
Bug: v8:12868
Change-Id: I122f448c0c7dad723d58a33a8509fbdfce1ea16c
Fixed: 333275999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5447114
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93376}
When fuzzing, we enable --wasm-sync-tier-up via flag implication,
which contrary to production code didn't reset the tiering budget
when triggering tier-up, and didn't check whether the function is
already tiered up. So for long-running loops, we executed a fresh
synchronous compilation job at each back edge.
This patch fixes both problems: it resets the tiering budget, and
skips repeated tier-up requests when the NativeModule already has
optimized code for the given function.
Fixed: 330745165
Change-Id: Ie733180f0b47cf07a2e26a1b7bc67eb3624428ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5412662
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93121}
The four instructions that take i8/i16 arrays as inputs (i.e.
string.{new,encode}_wtf{8,16}_array) already considered these
to be nullable references, but optimistically rejected inputs
that were statically known to have type "none".
That doesn't match the general principle of allowing implicit
upcasting, so this patch relaxes the decoder to permit "none"
types at validation time (they'll trap at runtime, of course).
Context: https://github.com/WebAssembly/stringref/issues/66
Bug: v8:12868
Change-Id: I813f8adc273c9e7ac23590ce239e47ce6117973b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5385442
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92942}
Segmenting a string into words or graphemes returns a
"Segment Data Object" for every segment. By predefining these
objects' map, we can populate their properties much faster than
with CreateDataProperty().
This speeds up the microbenchmark from the linked bug (c#5) by
around 3x.
Bug: 326176949
Change-Id: I2791143f514654ab3d1673a94169b4fb96238840
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5382161
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92928}
When an Isolate shuts down at an inconvenient moment and instructs its
task runner to destroy all waiting tasks, these tasks must not free
memory that later steps in the Isolate shutdown sequence will still
write to. This patch fixes such a situation for ClearWeakScriptHandleTasks
by letting the Isolate itself own the memory in question.
I have never been able to reproduce the reported issue myself, so
this is a somewhat speculative fix.
Fixed: 326607001
Change-Id: Ie708439d924e9344c2df6bbba1cd864336756881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5372733
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92882}
When we implement `ref.as_non_null` as a fake load from the object
(which would trap if the object is null, handled by the trap handler),
we should take into account that the object base address is tagged,
so the "word after the map word" is at offset +3, not +4. Otherwise,
in the special case where the object is a non-null zero-fields struct
that was allocated right before the end of a page, we'd get an invalid
memory access and hence erroneously consider the struct to be `null`.
Fixed: 329145803
Change-Id: Ib8ce2668b767de9de6bf4632b022c71a3b8bd027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5378140
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92879}
- Mostly making unreachable code paths easier for the compiler
to detect
- Dropping one unused field from a struct
- Dropping one unnecessary std::move preventing copy elision
Other target platforms than x64 may need additional fixes.
The build takes a long time but it does finish eventually.
Change-Id: I314b1ca41959d7433d83bc2065facdcada91cc52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5318004
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92877}
We used to have a special case to make "op1 == op2" return true if
both ops were NaN constants (with possibly different bit patterns).
This special case is unnecessary for JavaScript, because we canonicalize
JS NaNs anyway, and a spec violation for Wasm, because Wasm must
preserve the payloads of NaN values that are being passed around.
Fixed: 328209289
Change-Id: I7a4595b72f17643d57cfd1e739d9a5409fb5bd0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5366030
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92847}
and treat them like exceeding "max steps".
This is meant to handle cases where randomly-generated functions
allocate many live heap objects, which would previously crash
the fuzzer process when running into the heap limit.
Fixed: 328146362
Change-Id: Id998947a57c94c5ad2e3a978aa1cd1015ab78f59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5366886
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92823}
Consider the following scenario:
[previous code]
b.eq label # instruction 0
[20KB of code]
tbz label # instruction 1
[20KB of code]
tbz label # instruction 2
[12KB of code]
<<< position 1
[around 960KB of code]
<<< position 2
[more code]
label:
When we reach "position 1", instruction #1 is reaching the end of its
encodable jump distance, so we emit a veneer for it. We would like to
rewire the instruction chain so that instruction #2 points at #0, but
that is also out of encodable range, so we make instruction #0 branch
to the veneer as well, and mark instruction #2 as the end of the chain
of linked branch instructions referring to the label.
However, instruction #0 is still in the list of unresolved branches,
from which we must remove it; otherwise when we reach position 2,
where instruction #0's encodable jump distance ends, we will try to
emit a veneer for it, which involves trying to find it by walking the
label's chain of linked instructions -- where we won't find it, because
that chain now ends at instruction #2.
This bug was flushed out by --turboshaft-wasm, but is neither Wasm nor
Turboshaft specific (e.g. in a local repro that is too slow to check
in as a regression test, I can trigger it with Turbofan as well).
Fixed: 328738218
Change-Id: Ic98eaddbecf52bce72e25ea256e1f00d33a29b66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5367100
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92817}
It turns out that the right combination of instructions from the
stringref proposal also ends up on the fast path we built for
imported strings, where we shortcut an array-from-data and a
string-from-array operation to a combined string-from-data. Since
stringref instructions support additional strictness modes
(specifically: kUtf8NoTrap, i.e. attempt strict UTF-8 decoding, and
return `null` instead of trapping on failure), the fast path needs
to support these too.
Fixed: v8:14657
Change-Id: I4610cf821e709d56459fb5b1b2515d4bf4c691fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5355703
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92757}
Requesting division by zero (which is only possible with already-
corrupted heap contents) should CHECK-fail in Release mode to
prevent subsequent escalation to off-heap memory corruption.
Fixed: 328692018
Change-Id: If7b96eac0a39eb0de3185d5851528549e2b8e47d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5355705
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92736}
There were two bugs:
- Turboshaft failed to take the fast path despite meaning to.
- The fast path accidentally inherited the stringref proposal's
stricter throw-on-invalid-data behavior, while imported string
operations are supposed to silently use the replacement character.
Fixed: 327643791
Change-Id: I536c8355d2a8e4dcd4f41af16a0fa1da062aef4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5345411
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92672}
And also expose uint64_t printing.
This CL is just moving code in preparation for future work, there
are zero functional changes here.
Change-Id: Ic140a0e44bc08be476741096084d7f5256074f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5339907
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92656}
When building Wasm modules from asm.js sources, we should use
unsigned LEBs where appropriate, specifically: for global indices
and branch depths.
Using signed LEBs should be harmless, but is wasteful, because it
can require an additional byte that would be avoidable. For an
extreme example, see "TestLargeSwitch" near the end of
test/mjsunit/wasm/asm-wasm-switch.js.
Change-Id: Id04f4ca51819b3054ff6589bdbcb54113dbdc814
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5339888
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92651}
We erroneously marked the optimized string-from-data path (replacing an
array-from-data + string-from-array sequence) as "eliminatable", which
means when its result is unused, the operation could be dropped entirely,
even when it would have trapped.
To avoid differences in trapping behavior between optimized/unoptimized
code, we must never eliminate this operation.
Fixed: 326260438
Change-Id: If15c0b66455e70c4ee51f3c4f69e07f4e87d1366
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5314730
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92475}
- Switch --wasm-tier-mask-for-testing to apply to declared (as opposed
to possibly-imported) function indices. This makes sure that the
fuzzer's selection of functions to be optimized has an effect.
- Disable lazy compilation for the fuzzer, to make sure we compile
everything right away.
- Before giving up on a generated module that runs for too long, tier
up all functions in it, to possibly catch compiler DCHECKs. To avoid
non-determinism, we perform this tier-up synchronously on the main
thread, using a new flag --wasm-sync-tier-up.
- Make the fuzzer check for compile-time imports properly.
- Leave tiering enabled for fuzzer runs, to be closer to production
behavior and enable inlining based on call counts.
- Fix: when clearing the global type canonicalizer, also clear the
per-heap list of cached canonical RTTs to prevent them from being
reused erroneously.
- Fix: when checking whether a function should be compiled with
Turboshaft, compare the mask bit "!= 0" instead of "== 1".
Changes:
Change-Id: I11ac329b82bc9c8acb5157bc418ee48b2a85198f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5314659
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92463}
Our somewhat simplistic detection mechanism for long-running
randomly-generated modules relies on counting executed Wasm
instructions. Some instructions ("bulk" instructions operating
on tables/memories/arrays/strings) can take significantly longer
to execute than simple instructions, so when functions used many
of those, they could run long enough to cause timeouts without
bumping into the "max steps" budget. This CL mitigates that by
marking relevant instructions as "heavy", so they count as 1000
steps.
We could be fancier and take actual lengths into account, but
perhaps this simple approach is good enough.
Fixed: 325738876
Change-Id: Ib325be4d6864db2840ec7d81a6d13cdf24fd01ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5307538
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92418}
The automatic args.gn update to apply the goma->reclient change
only worked for "managed" output directories; this patch brings
them to "manual mode" output directories (`gm out/foo`).
No-Try: true
Change-Id: Ia970d111f612cbd907cc370981f6c8cb744a9795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5306762
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92415}
The node we query is invalid in unreachable code, so we must check
for that before fetching it from the graph.
Bonus: running the regression test in Turbofan revealed an unrelated
issue having to do with reachability of catch blocks after replacing
a well-known import, so this CL includes a fix for that too.
Fixed: chromium:324690505
Change-Id: If648faf7dd466ed857d723eec44fc01fc7a6a6fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5300801
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92362}
- Print recgroups
- Print "sub" and "sub final" instead of outdated "_subtype" suffix
- Since offsets must now always be computed, the performance impact
is mitigated by collecting them during initial decoding when we
are decoding just for the disassembler. (When disassembling an
existing module, we have no choice but to let the OffsetsProvider
decode it again.)
Bug: v8:14034
Change-Id: I41f55d597e05fae7e6599a7810240ed4ce25a1fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5286275
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92280}
Optimizing compilers must not optimize out string.from_codepoint even
when the result is unused, because an invalid codepoint traps, which
is observable.
Drive-by fix: Liftoffs corresponding error message in the imported
strings variant didn't include the to-uint conversion of the codepoint.
Fixed: chromium:324475066
Change-Id: I0066350da25936b3b48ae0f2c1b3adb89aa77133
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5279449
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92257}
This adds support for imported strings to the wasm-compile fuzzer.
Drive-by: fix the first bug that this fuzzing support uncovered,
which is an over-zealous DCHECK when validating modules that have
no imports but enable compile-time imports.
Bug: v8:14179
Change-Id: I6a2b3dea76456f42df4f8cae499eee5d32736342
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5253193
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92201}
The final loop in this test had a typo in its starting point, which
caused it to skip an interesting value, and a typo in its end point,
which caused it to do much more work than intended.
Change-Id: I7604b95478f6975244932339607607bc089c1750
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5263197
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92184}
When only the generational and/or shared write barries are
needed, we can skip pointers to uninteresting targets quickly
if they are located on a page that has already been determined
to be uninteresting. Remembering all uninteresting pages would
be slow, but remembering the last uninteresting page improves
a microbenchmark by around 2x.
Change-Id: I15c9b72608971d61f5964e1b00c8f59d11a54bf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5262698
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92182}
This refactors the wasm-compile fuzzer to use arrays of struct/array
type indices instead of implicitly-known ranges of type indices.
This mirrors how function signature types have already been handled.
This is a prerequisite for adding fuzzer support for imported strings,
the included addition of default i8/i16 array types is a first step
in this direction.
Bug: v8:14179
Change-Id: I6d46d3a75a50640523c7a14fc4da11b7de4d909d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5253192
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92151}
This ports crrev.com/c/4035091 to Liftoff: ia32 and x64 can use
`blendvps` and `blendvpd` for 32/64 bit wide lane selection, as
opposed to using bytewise selection regardless of lane width.
Turbofan/Turboshaft do this already; this patch brings the same
logic to Liftoff, ensuring that functions compute the same results
before and after optimization.
Fixed: chromium:1516878
Change-Id: Iff69603954661cf2701fe48805edc3e41dc2307c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5239025
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92065}
The MachineOperatorReducer can create the situation that an atomic
store has both an index and a displacement, which the ia32
instruction selector didn't support.
Fixed: chromium:1520312
Change-Id: I291dcf2915c9ecd9002c0e0ddc5a46b3bf5db158
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5237267
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92006}
Int64Lowering currently cannot deal with "elem_size_log2" scaling
parameters, because AtomicWord32Pair doesn't support them. So the
MachineOptimizationReducer shouldn't produce these parameters on
this particular configuration.
Fixed: chromium:1520311
Change-Id: I68f5cf48fc2d617bd62aeced018983eb6e77d56c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5232164
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91985}
When unifying this with other ReplaceLane operations in
crrev.com/c/5191568, I missed that there was a difference
in "g.Use" vs. "g.UseRegister".
Fixed: chromium:1520130
Change-Id: I7c985c57b439dba4b2765cf93294d0c77af127fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5227862
Reviewed-by: Eva Herencsárová <evih@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eva Herencsárová <evih@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91963}
This fixes an issue in crrev.com/5180736 where an atomic memory
access with a statically known index and incorrect alignment
does not trap even though it should.
Fixed: chromium:1520780
Change-Id: I0f59728acbfd5a8ca02c67ebf5093e8be923e1c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5224982
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91950}
All WebAssembly.* functions that can trigger compilation get an
additional "options" parameter, which for now can express a list
of built-in imports packages that the module wishes to use. These
imports are then available at compile time already, and are ignored
at instantiation time.
Bug: v8:14179
Change-Id: I64f89a8a2e1f817199c877235c2b018e5e150ad1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5217133
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91931}
Keeping up with the upstream proposal:
- "MeasureUTF8" and "IntoUTF8Array" are new,
- "FromUTF8Array" replaces "FromWTF8Array",
- the internal debug names of the string builtins are updated;
updating their public names will follow in the next CL.
Also, "Cast" and "Test" get Turbofan implementations (to avoid a
dependency on the Turboshaft launch).
Bug: v8:14179
Change-Id: Idbb4de7e3e3b56cfb44c15651cbea9d4fb1b6d85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5217053
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@{#91924}
We checked the conditions in the wrong order: machines that have
both "rbe_instance" and "download_remoteexec_cfg" in their .gclient
must be classified as non-Google.
No-Try: true
Change-Id: Ib9331531709b7bea6fcba5e31a24d010554e9ecd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5217151
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91923}
To read the current size of a CompilationStateImpl more accurately,
we need to acquire a mutex, which can deadlock when that mutex is
held elsewhere by another thread. To fix this, we replace the
mutex-guarded field reading with heuristics, which should only cause
a small loss of accuracy in this case.
Fixed: chromium:1497386
Change-Id: Ice6c4e6ff96235ff688b26c8837575a37e97e492
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5199991
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91861}
Jakob Kummerow