1. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      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}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  2. 16 Feb, 2021 2 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
  3. 11 Feb, 2021 1 commit
  4. 22 May, 2017 1 commit
  5. 22 Sep, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · e5ac75c6
      rmcilroy authored
      This CL optimizes the code in BytecodeArrayBuilder and
      BytecodeArrayWriter by making the following main changes:
      
       - Move operand scale calculation out of BytecodeArrayWriter to the
      BytecodeNode constructor, where the decision on which operands are
      scalable can generally be statically decided by the compiler.
       - Move the maximum register calculation out of BytecodeArrayWriter
      and into BytecodeRegisterOptimizer (which is the only place outside
      BytecodeGenerator which updates which registers are used). This
      avoids the BytecodeArrayWriter needing to know the operand types
      of a node as it writes it.
       - Modify EmitBytecodes to use individual push_backs rather than
      building a buffer and calling insert, since this turns out to be faster.
       - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      bytes,
       - Make common functions in Bytecodes constexpr so that they
      can be statically calculated by the compiler.
       - Move common functions and constructors in Bytecodes and
      BytecodeNode to the header so that they can be inlined.
       - Change large static switch statements in Bytecodes to const array
      lookups, and move to the header to allow inlining.
      
      I also took the opportunity to remove a number of unused helper
      functions, and rework some others for consistency.
      
      This reduces the percentage of time spent in making BytecodeArrays
       in  CodeLoad from ~15% to ~11% according to perf. The
      CoadLoad score increase by around 2%.
      
      BUG=v8:4280
      
      Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
      Review-Url: https://codereview.chromium.org/2351763002
      Cr-Original-Commit-Position: refs/heads/master@{#39599}
      Cr-Commit-Position: refs/heads/master@{#39637}
      e5ac75c6
    • hablich's avatar
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.... · 5d693348
      hablich authored
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. (patchset #6 id:200001 of https://codereview.chromium.org/2351763002/ )
      
      Reason for revert:
      Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/
      
      Original issue's description:
      > [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.
      >
      > This CL optimizes the code in BytecodeArrayBuilder and
      > BytecodeArrayWriter by making the following main changes:
      >
      >  - Move operand scale calculation out of BytecodeArrayWriter to the
      > BytecodeNode constructor, where the decision on which operands are
      > scalable can generally be statically decided by the compiler.
      >  - Move the maximum register calculation out of BytecodeArrayWriter
      > and into BytecodeRegisterOptimizer (which is the only place outside
      > BytecodeGenerator which updates which registers are used). This
      > avoids the BytecodeArrayWriter needing to know the operand types
      > of a node as it writes it.
      >  - Modify EmitBytecodes to use individual push_backs rather than
      > building a buffer and calling insert, since this turns out to be faster.
      >  - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      > bytes,
      >  - Make common functions in Bytecodes constexpr so that they
      > can be statically calculated by the compiler.
      >  - Move common functions and constructors in Bytecodes and
      > BytecodeNode to the header so that they can be inlined.
      >  - Change large static switch statements in Bytecodes to const array
      > lookups, and move to the header to allow inlining.
      >
      > I also took the opportunity to remove a number of unused helper
      > functions, and rework some others for consistency.
      >
      > This reduces the percentage of time spent in making BytecodeArrays
      >  in  CodeLoad from ~15% to ~11% according to perf. The
      > CoadLoad score increase by around 2%.
      >
      > BUG=v8:4280
      >
      > Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
      > Cr-Commit-Position: refs/heads/master@{#39599}
      
      TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2360193003
      Cr-Commit-Position: refs/heads/master@{#39612}
      5d693348
  6. 21 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · b11a8b4d
      rmcilroy authored
      This CL optimizes the code in BytecodeArrayBuilder and
      BytecodeArrayWriter by making the following main changes:
      
       - Move operand scale calculation out of BytecodeArrayWriter to the
      BytecodeNode constructor, where the decision on which operands are
      scalable can generally be statically decided by the compiler.
       - Move the maximum register calculation out of BytecodeArrayWriter
      and into BytecodeRegisterOptimizer (which is the only place outside
      BytecodeGenerator which updates which registers are used). This
      avoids the BytecodeArrayWriter needing to know the operand types
      of a node as it writes it.
       - Modify EmitBytecodes to use individual push_backs rather than
      building a buffer and calling insert, since this turns out to be faster.
       - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      bytes,
       - Make common functions in Bytecodes constexpr so that they
      can be statically calculated by the compiler.
       - Move common functions and constructors in Bytecodes and
      BytecodeNode to the header so that they can be inlined.
       - Change large static switch statements in Bytecodes to const array
      lookups, and move to the header to allow inlining.
      
      I also took the opportunity to remove a number of unused helper
      functions, and rework some others for consistency.
      
      This reduces the percentage of time spent in making BytecodeArrays
       in  CodeLoad from ~15% to ~11% according to perf. The
      CoadLoad score increase by around 2%.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2351763002
      Cr-Commit-Position: refs/heads/master@{#39599}
      b11a8b4d