1. 02 Mar, 2020 1 commit
  2. 20 Feb, 2020 1 commit
  3. 10 Feb, 2020 1 commit
  4. 02 Sep, 2019 1 commit
  5. 23 Aug, 2019 1 commit
    • Dan Elphick's avatar
      [compiler] Skip creating unneeded objects for lazy source positions · 735f3a68
      Dan Elphick authored
      This changes Compiler::CollectSourcePositions to skip finalization of
      the BytecodeArray, constant table, handler table, ScopeInfos as well as
      internalization of Ast values since only the source position table is
      used and the others will be collected soon after by the GC.
      
      It will also now avoid recompiling inner functions that would otherwise
      be eagerly compiled.
      
      BytecodeArrayWriter::ToBytecodeArray has been changed to never populate
      the source_position_table.
      
      Bug: v8:8510
      Change-Id: I2db2f2da6b48fde11f17a20d017c1a54c0a34fc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763538
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63365}
      735f3a68
  6. 24 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  8. 28 Feb, 2019 3 commits
    • Leszek Swirski's avatar
      Reland "[ignition] Skip binding dead labels" · c7ebc581
      Leszek Swirski authored
      This is a reland of 35269f77
      
      Switches on an expression that unconditionally throws would have all their
      case statements dead, causing a DCHECK error in the SwitchBuilder. This
      fixes up the DCHECK to allow dead labels.
      
      Original change's description:
      > [ignition] Skip binding dead labels
      >
      > BytecodeLabels for forward jumps may create a dead basic block if their
      > corresponding jump was elided (due to it dead code elimination). We can
      > avoid generating such dead basic blocks by skipping the label bind when
      > no corresponding jump has been observed. This works because all jumps
      > except JumpLoop are forward jumps, so we only have to special case one
      > Bind for loop headers to bind unconditionally.
      >
      > Since Binds are now conditional on a jump existing, we can no longer rely
      > on using Bind to get the current offset (e.g. at the beginning of a try
      > block). Instead, we now expose the current offset in the bytecode array
      > writer. Conveniently, this means that we can be a bit smarter about basic
      > blocks around these statements.
      >
      > As a drive-by, remove the unused Bind(target,label) function.
      >
      > Bug: chromium:934166
      > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      > Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59942}
      
      TBR=rmcilroy@chromium.org
      
      Bug: chromium:934166
      Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
      Reviewed-on: https://chromium-review.googlesource.com/c/1494535Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59948}
      c7ebc581
    • Sigurd Schneider's avatar
      Revert "[ignition] Skip binding dead labels" · 8ee20f5e
      Sigurd Schneider authored
      This reverts commit 35269f77.
      
      Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
      
      Original change's description:
      > [ignition] Skip binding dead labels
      > 
      > BytecodeLabels for forward jumps may create a dead basic block if their
      > corresponding jump was elided (due to it dead code elimination). We can
      > avoid generating such dead basic blocks by skipping the label bind when
      > no corresponding jump has been observed. This works because all jumps
      > except JumpLoop are forward jumps, so we only have to special case one
      > Bind for loop headers to bind unconditionally.
      > 
      > Since Binds are now conditional on a jump existing, we can no longer rely
      > on using Bind to get the current offset (e.g. at the beginning of a try
      > block). Instead, we now expose the current offset in the bytecode array
      > writer. Conveniently, this means that we can be a bit smarter about basic
      > blocks around these statements.
      > 
      > As a drive-by, remove the unused Bind(target,label) function.
      > 
      > Bug: chromium:934166
      > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      > Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59942}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org
      
      Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:934166
      Reviewed-on: https://chromium-review.googlesource.com/c/1494534Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59947}
      8ee20f5e
    • Leszek Swirski's avatar
      [ignition] Skip binding dead labels · 35269f77
      Leszek Swirski authored
      BytecodeLabels for forward jumps may create a dead basic block if their
      corresponding jump was elided (due to it dead code elimination). We can
      avoid generating such dead basic blocks by skipping the label bind when
      no corresponding jump has been observed. This works because all jumps
      except JumpLoop are forward jumps, so we only have to special case one
      Bind for loop headers to bind unconditionally.
      
      Since Binds are now conditional on a jump existing, we can no longer rely
      on using Bind to get the current offset (e.g. at the beginning of a try
      block). Instead, we now expose the current offset in the bytecode array
      writer. Conveniently, this means that we can be a bit smarter about basic
      blocks around these statements.
      
      As a drive-by, remove the unused Bind(target,label) function.
      
      Bug: chromium:934166
      Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59942}
      35269f77
  9. 08 Nov, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] More accurate dead statement elision · 74125939
      Leszek Swirski authored
      The Ignition statement list visitor will skip the rest of the
      statements in the list if it hits a jump statement (like a return
      or break), as the rest of the code in the list can be considered
      dead.
      
          return;
          dead_call(); // skipped
      
      However, since this is at an AST node level, it does not take into
      account condition shortcutting:
      
          if(2.2) return;
          dead_call(); // not skipped
      
      There is also a second dead code elimination in Ignition compilation, at
      the bytecode array writer level, where a bytecodes are not emitted if an
      "exit" bytecode (Return, Jump, or a few others) has been written, until
      the next basic block starts (i.e. a Bind).
      
      This can cause an issue with statements that resurrect the bytecode
      array writer part-way through their visit. An example is try-catch
      statements, which save the context to a register, and then Bind to start
      the try region.
      
      For the case:
      
          if (2.2) return;
          try {     // try statement not skipped
              ...
          }
      
      the bytecode writer is called with
      
          OutputReturn()             // exit bytecode seen
          OutputMove(<context>, r1)  // not emitted
          Bind(&try_begin)           // starts new basic block
          // try body
      
      So, the try is emitted, but without saving the context to a register.
      This means that the liveness analysis sees the read of that register
      (as the output liveness of throwing bytecodes), but does not have a
      write to the register, which means that the liveness escapes.
      
      This patch fixes this by using the bytecode array writer dead-code
      elimination (i.e. "exit bytecode seen") to inform the statement list
      visitor, so that in this example the try statement is not visited at
      all.
      
      Bug: chromium:902395
      Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
      Reviewed-on: https://chromium-review.googlesource.com/c/1322951Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57350}
      74125939
  10. 27 Feb, 2018 1 commit
  11. 20 Oct, 2017 1 commit
  12. 19 Oct, 2017 1 commit
  13. 27 Jun, 2017 1 commit
  14. 23 Jun, 2017 1 commit
  15. 15 May, 2017 1 commit
  16. 12 Apr, 2017 1 commit
  17. 11 Apr, 2017 2 commits
  18. 17 Oct, 2016 1 commit
  19. 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
  20. 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
  21. 18 Aug, 2016 1 commit
  22. 08 Jul, 2016 1 commit
  23. 28 Jun, 2016 2 commits
  24. 10 Jun, 2016 1 commit
  25. 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
  26. 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