1. 15 Feb, 2021 1 commit
  2. 09 Feb, 2021 1 commit
  3. 05 Feb, 2021 1 commit
  4. 29 Jan, 2021 1 commit
  5. 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
  6. 12 Jan, 2021 1 commit
  7. 14 Dec, 2020 1 commit
  8. 10 Dec, 2020 1 commit
  9. 09 Dec, 2020 1 commit
  10. 07 Dec, 2020 3 commits
  11. 03 Dec, 2020 2 commits
  12. 02 Dec, 2020 2 commits
  13. 30 Nov, 2020 1 commit
  14. 25 Nov, 2020 2 commits
  15. 17 Nov, 2020 1 commit
  16. 10 Nov, 2020 1 commit
  17. 09 Nov, 2020 1 commit
  18. 03 Nov, 2020 3 commits
  19. 02 Nov, 2020 2 commits
  20. 27 Oct, 2020 2 commits
  21. 20 Oct, 2020 1 commit
  22. 15 Oct, 2020 1 commit
  23. 18 Sep, 2020 1 commit
  24. 02 Sep, 2020 1 commit
  25. 27 Aug, 2020 1 commit
  26. 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
  27. 10 Aug, 2020 2 commits
    • 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
    • Ng Zhi An's avatar
      [wasm-simd][arm] Use vmov to move all ones to register · 57242a05
      Ng Zhi An authored
      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: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69315}
      57242a05
  28. 25 Jun, 2020 1 commit
  29. 24 Jun, 2020 1 commit
  30. 23 Jun, 2020 1 commit