1. 15 Dec, 2016 1 commit
  2. 24 Oct, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Optimize the Register Optimizer. · ed7bef5b
      rmcilroy authored
      Modify the Bytecode Register Optimizer to be an independent component
      rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
      can explicitly call it with register operands when outputting a bytecode
      and the Bytecode Register Optimizer doesn't need to work out which operands
      are register operands. This also means we don't need to build BytecodeNodes
      for Ldar / Star / Mov bytecodes unless they are actually emitted by the
      optimizer.
      
      This change also modifies the way the BytecodeArrayBuilder converts
      operands to make use of the OperandTypes specified in bytecodes.h.
      This avoids having to individually convert operands to their raw output
      value before calling Output(...).
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2393683004
      Cr-Commit-Position: refs/heads/master@{#40543}
      ed7bef5b
  3. 17 Oct, 2016 1 commit
  4. 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
  5. 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
  6. 20 Sep, 2016 1 commit
  7. 23 Aug, 2016 1 commit
  8. 18 Aug, 2016 1 commit
  9. 25 Jul, 2016 1 commit
  10. 15 Jul, 2016 1 commit
  11. 14 Jul, 2016 1 commit
  12. 13 Jul, 2016 1 commit
  13. 05 Jul, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce binary op bytecodes for Smi operand. · 40511877
      oth authored
      Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode.
      The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi,
      BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi.
      
      There are additional code stubs for these operations that are biased towards
      both the left hand and right hand operands being Smis.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2111923002
      Cr-Commit-Position: refs/heads/master@{#37531}
      40511877
  14. 28 Jun, 2016 1 commit
  15. 21 Jun, 2016 1 commit
  16. 10 Jun, 2016 1 commit
  17. 09 Jun, 2016 1 commit
  18. 03 Jun, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Move jump processing to bytecode array writer. · de9d1d8b
      rmcilroy authored
      This moves processing of jumps out of bytecode array builder and into
      bytecode array writer. This simplifies the pipeline by avoiding having
      to flush for offset and patch up offsets in bytecode array builder based
      on what was emitted by the bytecode array writer.
      
      This also enables future refactorings to add dead code elimination back
      into the pipeline, and move processing of scalable operand sizes to the
      end of the pipeline (in the bytecode array writer) rather than having to
      deal with scalable operand types throughout pipeline.
      
      BUG=v8:4280,chromium:616064
      
      Review-Url: https://codereview.chromium.org/2035813002
      Cr-Commit-Position: refs/heads/master@{#36716}
      de9d1d8b
  19. 27 May, 2016 1 commit
  20. 25 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce fused bytecodes for common sequences. · 25b3fe79
      oth authored
      This change introduces five fused bytecodes for common bytecode
      sequences on popular websites. These are LdrNamedProperty,
      LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
      load values into a destination register operand instead of the
      accumulator. They are emitted by the peephole optimizer.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1985753002
      Cr-Commit-Position: refs/heads/master@{#36507}
      25b3fe79
  21. 23 May, 2016 1 commit
    • oth's avatar
      [Interpreter] Preserve source positions in peephole optimizer. · e43fbde7
      oth authored
      The original peephole optimizer logic in the BytecodeArrayBuilder did
      not respect source positions as it was written before there were
      bytecode source positions. This led to some minor differences to
      FCG and was problematic when combined with pending bytecode
      optimizations. This change makes the new peephole optimizer fully
      respect source positions.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1998203002
      Cr-Commit-Position: refs/heads/master@{#36439}
      e43fbde7
  22. 12 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce bytecode generation pipeline. · 02b7373a
      oth authored
      This change introduces a pipeline for the final stages of
      bytecode generation.
      
      The peephole optimizer is made distinct from the BytecodeArrayBuilder.
      
      A new BytecodeArrayWriter is responsible for writing bytecode. It
      also keeps track of the maximum register seen and offers a potentially
      smaller frame size.
      
      R=rmcilroy@chromium.org
      LOG=N
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/1947403002
      Cr-Commit-Position: refs/heads/master@{#36220}
      02b7373a