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. 31 Mar, 2020 1 commit
  5. 15 Nov, 2019 1 commit
  6. 16 Oct, 2019 1 commit
  7. 24 May, 2019 1 commit
  8. 23 May, 2019 1 commit
  9. 03 Apr, 2019 1 commit
  10. 03 Sep, 2018 1 commit
  11. 26 Oct, 2017 1 commit
  12. 05 Sep, 2017 1 commit
  13. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  14. 26 Jun, 2017 1 commit
  15. 02 Jun, 2017 1 commit
    • jarin's avatar
      This is a first step towards reducing the number of stores/loads when... · f0645612
      jarin authored
      This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.
      
      Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
      
      Changes:
      
      - SuspendGenerator bytecode now takes register list to save.
      - ResumeGenerator was split into two bytecodes:
        * Resume generator reads the state out and marks the generator as
            'executing'.
        * RestoreGeneratorRegisters reloads the registers from
            the generator.
          + this required adding support for output register list.
      
      - Introduced generator_object_ register in the bytecode generator.
        * in subsequent CLs, I will make better use of it, the goal is
            to get rid if the .generator_object local variable.
      
      - Taught register optimizer to flush unassigned registers.
      
      BUG=v8:6379
      
      Review-Url: https://codereview.chromium.org/2894293003
      Cr-Commit-Position: refs/heads/master@{#45675}
      f0645612
  16. 15 Dec, 2016 1 commit
  17. 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
  18. 17 Oct, 2016 1 commit
  19. 14 Oct, 2016 1 commit
  20. 05 Oct, 2016 1 commit
  21. 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
  22. 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