1. 22 Mar, 2021 1 commit
  2. 12 Mar, 2021 1 commit
    • Andreas Haas's avatar
      [wasm][liftoff][arm64] Avoid x28 even without pointer compression · 8d0f5a04
      Andreas Haas authored
      Due to a recent change Liftoff used different register configurations
      in the pointer-compression and no-pointer-compression setups. This
      caused a mismatch between the registers used by Liftoff and the
      registers spilled by the WasmDebugBreak builtin.
      
      With this CL the same register configuration is used both with and
      without pointer compression. Even without x28 there are 24 registers
      that can be used. Moreover, 24 registers can be spilled without
      padding, which would be needed with 25 registers to preserve stack
      alignment.
      
      Drive-by change: Use Reglist in frame-constants on all platforms.
      
      R=jkummerow@chromium.org
      
      Bug: v8:7581
      Change-Id: Iae2892718e905a7995a3fdd7be7fd4d75bebb3dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752884
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73366}
      8d0f5a04
  3. 11 Mar, 2021 1 commit
  4. 24 Feb, 2021 1 commit
  5. 15 Feb, 2021 1 commit
  6. 09 Feb, 2021 1 commit
  7. 05 Feb, 2021 1 commit
  8. 29 Jan, 2021 1 commit
  9. 19 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [arm][arm64] Use normal fp semantics in JSEntry · a016c9fe
      Seth Brenith authored
      On arm64, Windows Performance Recorder gets confused by the fact that fp
      in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
      caller frame. The expected usage of fp is documented in [1]:
      
        The frame pointer (x29) is required for compatibility with fast stack
        walking used by ETW and other services. It must point to the previous
        {x29, x30} pair on the stack.
      
      In slightly more detail, the Windows function RtlWalkFrameChain is
      responsible for generating stack traces during profiling with Windows
      Performance Recorder, and that function relies on the rule quoted above.
      Notably, it does not make any effort to read the unwinding data that one
      could obtain with RtlLookupFunctionEntry. Stack walks using that data,
      such as those performed by WinDbg and the cctest StackUnwindingWin64,
      work fine.
      
      It would be convenient if we could use fp in a more standard way during
      JSEntry so that Windows profiling tools work correctly. (We can also
      reduce JSEntry by two instructions in doing so.)
      
      Both arm and arm64 currently put a -1 value on the stack at the location
      that fp points to. This could prevent accidental access during the
      epilog of JSEntry, where fp might be zero. However, we believe that this
      protection is no longer necessary, and any bug that causes a read from
      fp during the end of JSEntry would cause various CQ failures.
      
      [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
      
      Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72165}
      a016c9fe
  10. 12 Jan, 2021 1 commit
  11. 14 Dec, 2020 1 commit
  12. 10 Dec, 2020 1 commit
  13. 09 Dec, 2020 1 commit
  14. 07 Dec, 2020 3 commits
  15. 03 Dec, 2020 2 commits
  16. 02 Dec, 2020 2 commits
  17. 30 Nov, 2020 1 commit
  18. 25 Nov, 2020 2 commits
  19. 17 Nov, 2020 1 commit
  20. 10 Nov, 2020 1 commit
  21. 09 Nov, 2020 1 commit
  22. 03 Nov, 2020 3 commits
  23. 02 Nov, 2020 2 commits
  24. 27 Oct, 2020 2 commits
  25. 20 Oct, 2020 1 commit
  26. 15 Oct, 2020 1 commit
  27. 18 Sep, 2020 1 commit
  28. 02 Sep, 2020 1 commit
  29. 27 Aug, 2020 1 commit
  30. 11 Aug, 2020 1 commit
    • Ng Zhi An's avatar
      Reland "[wasm-simd][arm] Use vmov to move all ones to register" · 9b9c6b0e
      Ng Zhi An authored
      This is a reland of 57242a05
      
      no-sse4.1 builds were failing due to missing simd-scalar-lowering
      for s128.const, this reland adds that implementation.
      
      Original change's description:
      > [wasm-simd][arm] Use vmov to move all ones to register
      >
      > vceq(dst, dst, dst) does not seem to always set the register to all
      > ones. The right way should be be to use vmov (immediate) anyway. This
      > was not supported in the assembler yet, so we need changes to the
      > assembler, diassembler, and simulator.
      >
      > There is an unfortunate fork in logic in the simulator, due to the way
      > the switches are set up, vmov (imm) logic is duplicated across two
      > different cases, because the switch looks at the top bit of the
      > immediate. Refactoring this will be a bigger change that is irrelevant
      > for this bug, so I'm putting that off for now. Instead we extract the
      > core of vmov (imm) into helpers and call it in the two cases.
      >
      > Bug: chromium:1112124
      > Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Bill Budge <bbudge@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69315}
      
      Bug: chromium:1112124
      Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69346}
      9b9c6b0e
  31. 10 Aug, 2020 1 commit
    • Bill Budge's avatar
      Revert "[wasm-simd][arm] Use vmov to move all ones to register" · ff503fd4
      Bill Budge authored
      This reverts commit 57242a05.
      
      Reason for revert: regression tests fails:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31477
      
      Original change's description:
      > [wasm-simd][arm] Use vmov to move all ones to register
      > 
      > vceq(dst, dst, dst) does not seem to always set the register to all
      > ones. The right way should be be to use vmov (immediate) anyway. This
      > was not supported in the assembler yet, so we need changes to the
      > assembler, diassembler, and simulator.
      > 
      > There is an unfortunate fork in logic in the simulator, due to the way
      > the switches are set up, vmov (imm) logic is duplicated across two
      > different cases, because the switch looks at the top bit of the
      > immediate. Refactoring this will be a bigger change that is irrelevant
      > for this bug, so I'm putting that off for now. Instead we extract the
      > core of vmov (imm) into helpers and call it in the two cases.
      > 
      > Bug: chromium:1112124
      > Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Bill Budge <bbudge@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69315}
      
      TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org
      
      Change-Id: I5d9d1dcb81771f71001d959ec5a03a43a11c4233
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1112124
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347211Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69316}
      ff503fd4