1. 17 Mar, 2021 2 commits
  2. 11 Mar, 2021 1 commit
  3. 09 Mar, 2021 1 commit
    • pthier's avatar
      Reland "[sparkplug] Change bytecode offset mapping and introduce iterator." · 2966c896
      pthier authored
      This is a reland of a8b61ef5
      
      The main reason for the revert was not related to this CL and was fixed
      with https://crrev.com/c/2739646
      In addition debug output in d8.test.verifySourcePositions was removed
      due to TSAN complaints.
      
      Original change's description:
      > [sparkplug] Change bytecode offset mapping and introduce iterator.
      >
      > Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
      > create a mapping of bytecode offset <-> sparkplug pc.
      > These pairs were only recorded after builtin/runtime calls.
      > In preparation for deoptimizing to Sparkplug, we need a more precise
      > mapping.
      > With this CL, we record positions for every bytecode. Instead of storing
      > a pair of (bytecode offset, sparkplug pc), we store only the pc,
      > calculating the bytecode offset from the index in the mapping table.
      > For easier use an iterator to access the mapping is introduced.
      >
      > Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
      flaky failures.
      >
      > Bug: v8:11420, v8:11429
      > Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73186}
      >
      > Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6
      
      Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745335Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73293}
      2966c896
  4. 08 Mar, 2021 2 commits
  5. 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
  6. 04 Mar, 2021 4 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
    • Maya Lekova's avatar
      Revert "[sparkplug] Change bytecode offset mapping and introduce iterator." · 6fa780ff
      Maya Lekova authored
      This reverts commit a8b61ef5.
      
      Reason for revert: Looks like it breaks GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/35880/overview
      
      Original change's description:
      > [sparkplug] Change bytecode offset mapping and introduce iterator.
      >
      > Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
      > create a mapping of bytecode offset <-> sparkplug pc.
      > These pairs were only recorded after builtin/runtime calls.
      > In preparation for deoptimizing to Sparkplug, we need a more precise
      > mapping.
      > With this CL, we record positions for every bytecode. Instead of storing
      > a pair of (bytecode offset, sparkplug pc), we store only the pc,
      > calculating the bytecode offset from the index in the mapping table.
      > For easier use an iterator to access the mapping is introduced.
      >
      > Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
      > flaky failures.
      >
      > Bug: v8:11420, v8:11429
      > Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73186}
      
      Bug: v8:11420
      Bug: v8:11429
      Change-Id: Ie71e7ce234e7b9ab9a2ec99a983e9900f35baa44
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735397
      Auto-Submit: Maya Lekova <mslekova@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@{#73187}
      6fa780ff
    • pthier's avatar
      [sparkplug] Change bytecode offset mapping and introduce iterator. · a8b61ef5
      pthier authored
      Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
      create a mapping of bytecode offset <-> sparkplug pc.
      These pairs were only recorded after builtin/runtime calls.
      In preparation for deoptimizing to Sparkplug, we need a more precise
      mapping.
      With this CL, we record positions for every bytecode. Instead of storing
      a pair of (bytecode offset, sparkplug pc), we store only the pc,
      calculating the bytecode offset from the index in the mapping table.
      For easier use an iterator to access the mapping is introduced.
      
      Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
      flaky failures.
      
      Bug: v8:11420, v8:11429
      Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73186}
      a8b61ef5
  7. 02 Mar, 2021 1 commit
  8. 25 Feb, 2021 2 commits
  9. 24 Feb, 2021 3 commits
  10. 23 Feb, 2021 1 commit
  11. 22 Feb, 2021 3 commits
  12. 19 Feb, 2021 3 commits
  13. 17 Feb, 2021 5 commits
  14. 16 Feb, 2021 4 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
    • Toon Verwaest's avatar
      [sparkplug] Drop another TODO that was a design decision · a94fd865
      Toon Verwaest authored
      Baseline scratch registers don't include the regular kScratchRegister
      (for now at least) because the rest of the system doesn't use the
      ScratchRegisterScope (yet).
      
      Bug: v8:11429
      Change-Id: I7a2f27a814e262e5b14bd30b2ae53d53e173bcc3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697194Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72771}
      a94fd865
    • Leszek Swirski's avatar
      [sparkplug] Rename bytecode tracing functions · 0067fbb1
      Leszek Swirski authored
      Change the interpreter tracing functions to be generic unoptimized code
      tracing functions. The type of the code is now inferred from the frame,
      rather than passed in.
      
      Also expands the set of gn flags to explicitly enable unoptimized
      tracing, with a helper gn flags for enabling it for Ignition and for
      baseline (both just set unoptimized tracing to be enabled for now, we
      could split this up in the future though), and V8 flags separate tracing
      Ignition and tracing baseline.
      
      Bug: v8:11420, v8:11429
      Change-Id: I040c2628fe5744dcb38ef8623df3e34f9c86a5b8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692817
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72767}
      0067fbb1
  15. 15 Feb, 2021 6 commits
  16. 12 Feb, 2021 1 commit