It's been enabled by default since Chrome 91.
Bug: v8:6020
Change-Id: Id26b7fb0b7dffe19a88a6f0071dd59203b06415a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3957636
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83862}
--experimental-wasm-mv has been removed, and --wasm-loop-unrolling is on
by default.
Change-Id: I094870765031ef46fcec95e9071333e4e80f407b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302805
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78140}
In Liftoff, we were missing kS128 cases to load to/from stack.
For the x64 and ARM64 instruction selector, the calculation of
reverse_slot is incorrect for 128-bit values:
- reverse_slot += 2 (size of 128-bit values, 2 pointers)
- this copies from slot -2 into register
- but the value starts at slot -1, it occupies slots -1 and -2
- we end up copying slot -2 (most significant half) of the register, and
also slot -3, which is where rsi was store (Wasm instance addr)
- the test ends up with a different result every time
The calculation of reverse_slot is changed to follow how ia32 and ARM
does it, which is to start with
- reverse_slot = 0
- in the code-generator, add 1 to the slot
- then after emitting Peek operation, reverse_slot += 2
The fixes for x64 and ARM64 are in both instruction-selector and
code-generator.
ia32 and ARM didn't support writing kSimd128 values yet, it was only a
missing check in code-generator, so add that in.
For ARM, the codegen is more involved, vld1 does not support addressing
with an offset, so we have to do the addition into a scratch register.
Also adding a test for returning multiple v128. V128 is not exposed to
JavaScript, so we use a Wasm function call, and then an involved chain
of extract lanes, returning 6 i32 which we verify the values of. It
extracts the first and last lane of the i32x4 value in order to catch
bugs where we write or read to a wrong stack slot (off by 1).
The simd-scalar-lowering for kCall was only handling single s128 return,
we adopt the way i64-lowering handles kCall, so that is can now handle
any kinds of calls with s128 in the descriptor.
Bug: v8:10794
Bug: chromium:1115230
Change-Id: I2ccdd55f6292bc5794be78053b27e14da8cce70e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2355189
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69439}
