1. 11 Apr, 2017 2 commits
  2. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored
      Adds a collection of call bytecodes which have an implicit undefined
      receiver argument, for cases such as global calls where we know that the
      receiver has to be undefined. This way we can skip an LdaUndefined,
      decrease bytecode register pressure, and set a more accurate
      ConvertReceiverMode on the interpreter and TurboFan call.
      
      As a side effect, the "normal" Call bytecode now becomes a rare case
      (only with calls and super property calls), so we get rid of its 0-2
      argument special cases and modify CallProperty[N] to use the
      NotNullOrUndefined ConvertReceiverMode.
      
      Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
      Reviewed-on: https://chromium-review.googlesource.com/463287
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  3. 16 Feb, 2017 1 commit
    • Daniel Clifford's avatar
      [ignition] Optimize reloading of registers before Dispatch · bd21c2bd
      Daniel Clifford authored
      Before this patch, the registers needed for bytecode dispatch in interpreter
      handlers were inconsistently stored in the interpreter frame and/or kept in
      values that remained live across calls.
      
      After this patch, these registers are explicitly reloaded after calls, making it
      possible to elide the spills of those registers before the call in many cases.
      
      Some highlights from the CL:
      
      * Added methods to the CSA and InterpreterAssembler to efficiently store and
        load Smis values and Smi interpreter registers on x64 without explicit
        tagging/untagging.
      
      * Created Variables for all of the interpreter-internal values that need to be
        reloaded before bytecode dispatch at the end of an interpreter handler.
      
      * The bytecode offset can be written out early in a handler by marking it
        has having a call along it's critical path. By moving this early in a
        handler, it becomes possible to use memory operands for pushes used to
        marshall parameters when making calls.
      
      Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
      Reviewed-on: https://chromium-review.googlesource.com/442566
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43260}
      bd21c2bd
  4. 01 Feb, 2017 1 commit
  5. 10 Nov, 2016 1 commit
  6. 09 Nov, 2016 1 commit
  7. 27 Oct, 2016 1 commit
    • leszeks's avatar
      [ignition] Add a property call bytecode · c4d770b1
      leszeks authored
      This is a new bytecode which behaves (for now) exactly like Call,
      except that in turbofan graph building we can set the
      ConvertReceiverMode to NotNullOrUndefined.
      
      I observe a 1% improvement on Box2D, I'd expect a similar improvement on
      other OOP heavy code.
      
      Review-Url: https://codereview.chromium.org/2450243002
      Cr-Commit-Position: refs/heads/master@{#40610}
      c4d770b1
  8. 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
  9. 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
  10. 20 Sep, 2016 1 commit
  11. 13 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Merge {OsrPoll} with {Jump} bytecode. · c9864173
      mstarzinger authored
      This introduces a new {JumpLoop} bytecode to combine the OSR polling
      mechanism modeled by {OsrPoll} with the actual {Jump} performing the
      backwards branch. This reduces the overall size and also avoids one
      additional dispatch. It also makes sure that OSR polling is only done
      within real loops.
      
      R=rmcilroy@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2331033002
      Cr-Commit-Position: refs/heads/master@{#39384}
      c9864173
  12. 06 Sep, 2016 1 commit
  13. 29 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove special JSForInStep and JSForInDone. · 1915762c
      bmeurer authored
      These JavaScript operators were special hacks to ensure that we always
      operate on Smis for the magic for-in index variable, but this never
      really worked in the OSR case, because the OsrValue for the index
      variable didn't have the proper information (that we have for the
      JSForInPrepare in the non-OSR case).
      
      Now that we have loop induction variable analysis and binary operation
      hints, we can just use JSLessThan and JSAdd instead with appropriate
      Smi hints, which handle the OSR case by inserting Smi checks (that are
      always true). Thanks to OSR deconstruction and loop peeling these Smi
      checks will be hoisted so they don't hurt the OSR case too much.
      
      Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
      we have to lower it to JSLessThan to get the loop induction variable
      goodness.
      
      R=epertoso@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2289613002
      Cr-Commit-Position: refs/heads/master@{#38968}
      1915762c
  14. 25 Jul, 2016 1 commit
  15. 20 Jul, 2016 1 commit
  16. 19 Jul, 2016 1 commit
  17. 18 Jul, 2016 2 commits
  18. 15 Jul, 2016 1 commit
  19. 14 Jul, 2016 1 commit
  20. 13 Jul, 2016 1 commit
  21. 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
  22. 30 Jun, 2016 1 commit
  23. 28 Jun, 2016 1 commit
  24. 21 Jun, 2016 3 commits
  25. 10 Jun, 2016 1 commit
  26. 09 Jun, 2016 1 commit
    • oth's avatar
      [interpreter] Ensure optimizations preserve source positions. · a9af61d0
      oth authored
      The optimization stages in the bytecode generation pipeline must
      preserve source position information. Failure to preserve
      source position information could result in single stepping
      in the debugger misbehaving or mis-reporting in exception stack traces.
      
      This change adds tests intended to check optimizations do not damage
      source position info.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2042633002
      Cr-Commit-Position: refs/heads/master@{#36855}
      a9af61d0
  27. 27 May, 2016 1 commit
  28. 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
  29. 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
  30. 18 May, 2016 1 commit
  31. 17 May, 2016 3 commits
  32. 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
  33. 22 Apr, 2016 1 commit