Skip to content

V
V8
Switch branch/tag
  1. 18 Aug, 2020 2 commits
    • Milad Farazmand's avatar
      PPC/s390: [wasm][arm][arm64][liftoff] Allow loads from negative indices · 2638328d
      Milad Farazmand authored 
      Port 4765c70f

Original Commit Message:

    On arm, the root register points into the middle of the roots array to
    allow to use the full int12_t offset range. Therefore some offsets into
    the root array are negative. This CL changes the liftoff assembler for
    arm to allow loads from negative offsets.

    On arm64, offsets can also be negative when pointer compression is
    disabled.

    Additionally this CL changes the signature of
    LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow
    the LiftoffCompiler to provide negative indices.

    This CL does not come with a separate test yet. However, this changes is
    needed for https://crrev.com/c/2352784. Where there will also be a test.

R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ie286b0169a5f7a1de90e0ec7002bfac83383ea6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363127Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69456}
      2638328d
    • Andreas Haas's avatar
      [wasm][arm][arm64][liftoff] Allow loads from negative indices · 4765c70f
      Andreas Haas authored 
      On arm, the root register points into the middle of the roots array to
allow to use the full int12_t offset range. Therefore some offsets into
the root array are negative. This CL changes the liftoff assembler for
arm to allow loads from negative offsets.

On arm64, offsets can also be negative when pointer compression is
disabled.

Additionally this CL changes the signature of
LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow
the LiftoffCompiler to provide negative indices.

This CL does not come with a separate test yet. However, this changes is
needed for https://crrev.com/c/2352784. Where there will also be a test.

R=thibaudm@chromium.org

Bug: v8:7581
Change-Id: I0a97a62ff8e934d45a4494adfbc74a3e1149c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2359429Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69453}
      4765c70f
  3. 17 Aug, 2020 2 commits
    • 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
    • Jakob Kummerow's avatar
      [cleanup] Consistent comments on namespace ends · aefbcbdd
      Jakob Kummerow authored 
      This is a comment-only CL.

Change-Id: I002b1765bfa839982ab11c22f744734fdd34d4ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352788Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69417}
      aefbcbdd
  5. 14 Aug, 2020 1 commit
  7. 12 Aug, 2020 1 commit
  9. 11 Aug, 2020 1 commit
  11. 10 Aug, 2020 3 commits
  13. 06 Aug, 2020 2 commits
  15. 04 Aug, 2020 1 commit
  17. 03 Aug, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd][liftoff] Fix i64x2.shr_s overwriting scratch · d5c58d9d
      Ng Zhi An authored 
      x64's implementation of i64x2.shr_s was overwriting the scratch
register. kScratchRegister is used to hold the extracted lane of the
SIMD register, but in certain cases [0], is also used to back up the
value of rcx. When this happens, the supposed backed-up rcx was
overwritten (definitely) by each extract lane, so we end up restoring
an incorrect value of rcx, leading to an eventual crash in certain
benchmarks, when this extracted lane was used as a memory operand (see
linked bugs).

[0] when register holding the shift value is not rcx, which sarq_cl
relies on

Bug: v8:10752
Bug: chromium:1111522
Change-Id: Iaf3264e16f94e78bad4290783757f0b722d40411
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334354Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69208}
      d5c58d9d
  19. 28 Jul, 2020 1 commit
  21. 27 Jul, 2020 2 commits
  23. 24 Jul, 2020 1 commit
  25. 23 Jul, 2020 1 commit
  27. 22 Jul, 2020 5 commits
  29. 21 Jul, 2020 7 commits
  31. 17 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [liftoff] Fix missing stack move · 42b4f15a
      Clemens Backes authored 
      The {operator==} on {VarState} did not check the spill offset, so when
merging stack states, we forgot to move stack values if both source and
destination were stack slots, but at different offsets.
This CL fixes this by removing the {operator==}, because the semantics
(and use) are not clear, and it's only used in one place anyway.
The equality check was mostly redundant, so inlining it also makes the
code smaller and faster.

R=ahaas@chromium.org

Bug: v8:10702
Change-Id: I6c8b2cfd1002274175c9a17d305692e4631fd7dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304574Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68916}
      42b4f15a
  33. 15 Jul, 2020 1 commit
  35. 14 Jul, 2020 1 commit
  37. 10 Jul, 2020 6 commits