1. 24 Jun, 2021 1 commit
  2. 23 Jun, 2021 1 commit
    • Mihir Shah's avatar
      A jump-table implementation for constant case switch statements · 9711289d
      Mihir Shah authored
      The change is made since for switch statements with lots of cases,
      where each case is a constant integer, the emitted bytecode is still
      a series of jumps, when we can instead use a jump table.
      
      If there are 6 or more cases (similar to GCC) of Smi literals, and
      if the max Smi case minus the min Smi case is not more than 3 times
      the number of cases, we use a jump table up front to handle Smi's,
      and then use traditional if-else logic for the rest of the cases.
      
      We then use the jump table in interpreter/bytecode-jump-table to
      do the optimization.
      
      This tries to go off issue 9738 in v8's issue tracker. It is not
      exactly the same, since that recommends doing the work at JIT-time,
      but has similar ideas. It also partially goes off issue 10764.
      
      Bug: v8:9738
      Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75323}
      9711289d
  3. 21 Jun, 2021 2 commits
  4. 10 Jun, 2021 1 commit
  5. 08 Jun, 2021 2 commits
  6. 07 Jun, 2021 1 commit
  7. 11 May, 2021 1 commit
  8. 21 Apr, 2021 1 commit
  9. 20 Apr, 2021 1 commit
  10. 29 Mar, 2021 1 commit
  11. 25 Mar, 2021 1 commit
    • Patrick Thier's avatar
      Reland "Reland "[sparkplug][deoptimizer] Deoptimize to baseline."" · e438ae2d
      Patrick Thier authored
      This is a reland of e3ccb538
      
      No changes for the reland.
      This CL was speculatively reverted, but was not the cause of the problem.
      
      TBR=jgruber@chromium.org
      
      Original change's description:
      > Reland "[sparkplug][deoptimizer] Deoptimize to baseline."
      >
      > This is a reland of bdcd7d79
      >
      > Handle lazy deopts when the current bytecode is JumpLoop.
      > Instead of advancing to the next bytecode, re-execute the JumpLoop.
      >
      > TBR=jgruber@chromium.org, neis@chromium.org
      >
      > Original change's description:
      > > [sparkplug][deoptimizer] Deoptimize to baseline.
      > >
      > > If we have baseline code, deoptimize to baseline instead of the
      > > interpreter. The process is similar to deopting to the interpreter.
      > > We just use different builtins
      > > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
      > > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
      > > patch an interpreter frame to a baseline frame and continue execution in
      > > baseline code (based on the deopt type, at the current or next
      > > bytecode).
      > >
      > > Bug: v8:11420
      > > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#73609}
      >
      > Bug: v8:11420
      > Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035
      > Reviewed-by: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73636}
      
      Bug: v8:11420
      Change-Id: I7fbbb73a4fdaeab8b294862ee6ae952928c57994
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784695
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73656}
      e438ae2d
  12. 24 Mar, 2021 3 commits
    • Deepti Gandluri's avatar
      Revert "Reland "[sparkplug][deoptimizer] Deoptimize to baseline."" · ebc9f39f
      Deepti Gandluri authored
      This reverts commit e3ccb538.
      
      Reason for revert: Speculative revert for ARM 64 CFI fails - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/5174?
      
      Original change's description:
      > Reland "[sparkplug][deoptimizer] Deoptimize to baseline."
      >
      > This is a reland of bdcd7d79
      >
      > Handle lazy deopts when the current bytecode is JumpLoop.
      > Instead of advancing to the next bytecode, re-execute the JumpLoop.
      >
      > TBR=jgruber@chromium.org, neis@chromium.org
      >
      > Original change's description:
      > > [sparkplug][deoptimizer] Deoptimize to baseline.
      > >
      > > If we have baseline code, deoptimize to baseline instead of the
      > > interpreter. The process is similar to deopting to the interpreter.
      > > We just use different builtins
      > > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
      > > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
      > > patch an interpreter frame to a baseline frame and continue execution in
      > > baseline code (based on the deopt type, at the current or next
      > > bytecode).
      > >
      > > Bug: v8:11420
      > > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#73609}
      >
      > Bug: v8:11420
      > Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035
      > Reviewed-by: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73636}
      
      Bug: v8:11420
      Change-Id: Icd797b4979a114a2a627e12c8bb7d2215df03182
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785074Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73643}
      ebc9f39f
    • Patrick Thier's avatar
      Reland "[sparkplug][deoptimizer] Deoptimize to baseline." · e3ccb538
      Patrick Thier authored
      This is a reland of bdcd7d79
      
      Handle lazy deopts when the current bytecode is JumpLoop.
      Instead of advancing to the next bytecode, re-execute the JumpLoop.
      
      TBR=jgruber@chromium.org, neis@chromium.org
      
      Original change's description:
      > [sparkplug][deoptimizer] Deoptimize to baseline.
      >
      > If we have baseline code, deoptimize to baseline instead of the
      > interpreter. The process is similar to deopting to the interpreter.
      > We just use different builtins
      > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
      > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
      > patch an interpreter frame to a baseline frame and continue execution in
      > baseline code (based on the deopt type, at the current or next
      > bytecode).
      >
      > Bug: v8:11420
      > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73609}
      
      Bug: v8:11420
      Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73636}
      e3ccb538
    • Sathya Gunasekaran's avatar
      Revert "[sparkplug][deoptimizer] Deoptimize to baseline." · 6fc861e4
      Sathya Gunasekaran authored
      This reverts commit bdcd7d79.
      
      Reason for revert: 
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux%20Future/7996/blamelist
      
      Original change's description:
      > [sparkplug][deoptimizer] Deoptimize to baseline.
      >
      > If we have baseline code, deoptimize to baseline instead of the
      > interpreter. The process is similar to deopting to the interpreter.
      > We just use different builtins
      > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
      > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
      > patch an interpreter frame to a baseline frame and continue execution in
      > baseline code (based on the deopt type, at the current or next
      > bytecode).
      >
      > Bug: v8:11420
      > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73609}
      
      Bug: v8:11420
      Change-Id: Ie8b936df343b9194c0a6e50e0c44b67c0d9a012d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783030
      Auto-Submit: Sathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73621}
      6fc861e4
  13. 23 Mar, 2021 1 commit
  14. 17 Mar, 2021 1 commit
  15. 08 Mar, 2021 1 commit
  16. 05 Mar, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)" · eed72063
      Shu-yu Guo authored
      This is a reland of 0c63aa9e
      
      Fixes the correctness fuzzing BUILD.gn breakage.
      
      Original change's description:
      > [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
      >
      > Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
      > compression is enabled.
      >
      > This CL is to get performance numbers for reserving an extra register.
      > There is no actual pointer cage yet, and the base register will always
      > have the same value as the root register. The pointer decompression code
      > is switched to using the base register instead of the root register.
      >
      > Bug: v8:11460
      > Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73204}
      
      TBR=rmcilroy@chromium.org,jkummerow@chromium.org,leszeks@chromium.org
      
      Bug: v8:11460
      Change-Id: Iecf6b783392a384b40ab33e0f4ce13538a8f81ee
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737681Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73207}
      eed72063
  17. 04 Mar, 2021 2 commits
    • Shu-yu Guo's avatar
      Revert "[ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)" · 645631f2
      Shu-yu Guo authored
      This reverts commit 0c63aa9e.
      
      Reason for revert: Breaking clusterfuzz builds
      
      Original change's description:
      > [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
      >
      > Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
      > compression is enabled.
      >
      > This CL is to get performance numbers for reserving an extra register.
      > There is no actual pointer cage yet, and the base register will always
      > have the same value as the root register. The pointer decompression code
      > is switched to using the base register instead of the root register.
      >
      > Bug: v8:11460
      > Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73204}
      
      Bug: v8:11460
      Change-Id: Idebf1fc6eeeda880a21d65b6f2c674fa58690bfa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737812
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73205}
      645631f2
    • Shu-yu Guo's avatar
      [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28) · 0c63aa9e
      Shu-yu Guo authored
      Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
      compression is enabled.
      
      This CL is to get performance numbers for reserving an extra register.
      There is no actual pointer cage yet, and the base register will always
      have the same value as the root register. The pointer decompression code
      is switched to using the base register instead of the root register.
      
      Bug: v8:11460
      Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73204}
      0c63aa9e
  18. 24 Feb, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Fix instance type checks · e708bf69
      Leszek Swirski authored
      We were using CmpInstanceType instead of CmpObjectType in some places,
      which meant that we were reading the value at the instance type field
      offset within objects directly, rather than first loading their map and
      reading the instance type there.
      
      Bug: chromium:1180434
      Change-Id: I4771b4f8f9a32bdc35944c6e6cd30c54e4ac8b6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716292
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73003}
      e708bf69
  19. 22 Feb, 2021 2 commits
  20. 19 Feb, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Fix frame fill · cd76e360
      Leszek Swirski authored
      Change the frame fill to unconditionally subtract already pushed
      registers from register count. This ensures that the decision to add a
      push loop is dependent on the _remaining_ registers, not the _total_
      registers.
      
      Bug: v8:11420
      Change-Id: Ide763654e66f0a8c827a00fca1b4a77be2052f76
      Fixed: chromium:1179595
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704672
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72863}
      cd76e360
  21. 17 Feb, 2021 2 commits
  22. 16 Feb, 2021 1 commit
  23. 15 Feb, 2021 2 commits
  24. 12 Feb, 2021 1 commit