Skip to content

V
V8
Switch branch/tag
  1. 17 Aug, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd] Support returning Simd128 on caller's stack · 360c9294
      Ng Zhi An authored 
      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: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69439}
      360c9294
  3. 11 Aug, 2020 1 commit
  5. 31 Jul, 2020 2 commits
  7. 30 Jul, 2020 1 commit
  9. 16 Jul, 2020 1 commit
  11. 14 Jul, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd][arm64][arm] Fix v128.const · 7c10560d
      Ng Zhi An authored 
      There is a sign-extension bug happening when packing 2 32-bit ints into
a 64-bit int. We are OR-ing int32_t with a uint64_t, so an integral
conversion converts int32_t to uint64_t, which is a sign extension, and
this gives unexpected results for a negative value:

    0x80000000 | uint64_t{0} -> 0xffffffff80000000

What we want is 0x0000000080000000.

Created a helper function to do this work of combining two uint32_t
into one uint64_t. The use of this function will also ensure that
if callers passed a int32_t, it would first be converted to a
uint32_t, and will not have this sign extension bug.

Sneaked a small regression test into the existing v128.const cctest,
and also cleanup the loop to reset `expected` array to 0.

Bug: chromium:1104033
Change-Id: Icaca4c5ba42077dd4463697b9220cdbca9974b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2293044
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68850}
      7c10560d
  13. 10 Jul, 2020 1 commit
  15. 08 Jul, 2020 1 commit
  17. 07 Jul, 2020 1 commit
  19. 30 Jun, 2020 1 commit
  21. 19 Jun, 2020 1 commit
  23. 15 Jun, 2020 1 commit
  25. 03 Jun, 2020 1 commit
  27. 27 May, 2020 1 commit
  29. 21 May, 2020 1 commit
  31. 13 May, 2020 1 commit
  33. 11 May, 2020 2 commits
  35. 05 May, 2020 2 commits
  37. 01 May, 2020 1 commit
  39. 24 Apr, 2020 1 commit
  41. 06 Apr, 2020 1 commit
  43. 03 Apr, 2020 3 commits
  45. 31 Mar, 2020 1 commit
  47. 30 Mar, 2020 1 commit
  49. 25 Mar, 2020 1 commit
    • Seth Brenith's avatar
      Revert "Move branch inversion on ==0 into platform-agnostic reducer" · 252acd7f
      Seth Brenith authored 
      This reverts commit 0c72c719.

Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer

Original change's description:
> Move branch inversion on ==0 into platform-agnostic reducer
> 
> This change is based on a discussion from
> https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
> wherein Tobias suggested moving the folding away of ==0 operations out
> of the platform-specific instruction selectors and into the
> MachineOperatorReducer. I noticed that CommonOperatorReducer already
> handles some very similar cases, so I have tried putting the ==0 folding
> into CommonOperatorReducer instead. I'm happy to move it into
> MachineOperatorReducer if that's better; I still don't have a very good
> understanding of how roles are separated among reducers.
> 
> Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66688}

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:1061767
Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66862}
      252acd7f
  51. 17 Mar, 2020 2 commits
  53. 12 Mar, 2020 1 commit
  55. 28 Feb, 2020 2 commits
  57. 10 Feb, 2020 1 commit
  59. 07 Feb, 2020 1 commit
  61. 06 Feb, 2020 1 commit
  63. 04 Feb, 2020 2 commits