1. 11 Nov, 2019 1 commit
    • Jakob Gruber's avatar
      [interpreter] Move function-entry stack check to start of bytecode array · cebfde67
      Jakob Gruber authored
      The function-entry stack check should dominate all other
      instructions in a function. Prior to this CL it was possible to create
      paths not including a stack check due to SwitchOnGeneratorState: the
      generator-creation branch had a stack check, while generator-resume
      branches did not.
      
        0 : af fb 00 01       SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
        4 : 27 fe fa          Mov <closure>, r1
        7 : 27 02 f9          Mov <this>, r2
       10 : 64 0a fa 02       InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
       14 : 26 fb             Star r0
       16 : a7                StackCheck
       17 : b0 fb fb 01 00    SuspendGenerator r0, r0-r0, [0]
       22 : b1 fb fb 01       ResumeGenerator r0, r0-r0
                              [... no stack check here ...]
      
      This CL moves the stack check to the beginning of the bytecode array,
      i.e. before SwitchOnGeneratorState.
      
      Bug: chromium:1020031
      Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64888}
      cebfde67
  2. 11 Mar, 2019 1 commit
  3. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      [esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
      
      Fixes an error where TemplateLiteral printing in --print-ast
      would try to read an element beyond the length of a vector.
      
      BUG=v8:7415, chromium:820596
      R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
      Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612
  4. 10 Mar, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[esnext] re-implement template strings" · b8128279
      Michael Achenbach authored
      This reverts commit 8ae19e08.
      
      Reason for revert:
      Speculative revert for layout test:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22215
      
      See:
      https://github.com/v8/v8/wiki/Blink-layout-tests
      
      Original change's description:
      > [esnext] re-implement template strings
      > 
      > - Add a new bytecode for the ToString operation, replacing the old
      > intrinsic call (currently does not collect type feedback).
      > - Add a new AST node to represent TemplateLiterals, and avoid
      > generating unnecessary ToString operations in some simple cases.
      > - Use a single feedback slot for each string addition, because the
      > type feedback should always be the same for each addition
      > 
      > This seems to produce a very slight improvement on JSTests benchmarks
      > and bench-ruben.js from v8:7415, and it's possible that type feedback
      > for the ToString bytecode could provide more opportunities to eliminate
      > the runtime call in TurboFan.
      > 
      > Doesn't touch tagged templates
      > 
      > BUG=v8:7415
      > R=​rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      > 
      > Change-Id: If5a8c68558431f058db894d65776324abf54218e
      > Reviewed-on: https://chromium-review.googlesource.com/945408
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Cr-Commit-Position: refs/heads/master@{#51853}
      
      TBR=rmcilroy@chromium.org,caitp@igalia.com,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Id0529b065493ffc20c8f2b1abacc4c1484c3c046
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7415
      Reviewed-on: https://chromium-review.googlesource.com/958163Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51862}
      b8128279
  5. 09 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] re-implement template strings · 8ae19e08
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      BUG=v8:7415
      R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: If5a8c68558431f058db894d65776324abf54218e
      Reviewed-on: https://chromium-review.googlesource.com/945408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51853}
      8ae19e08
  6. 07 Mar, 2018 1 commit
  7. 25 Oct, 2017 1 commit
    • Leszek Swirski's avatar
      [parser] Add an n-ary node for large binop chains · 52ef2a1c
      Leszek Swirski authored
      Expressions of the form
      
          a_0 + a_1 + a_2 + a_3 + ... + a_n
      
      seem to be reasonably common for cases such as building templates.
      However, parsing these expressions results in a n-deep expression tree:
      
                 ...
                /
               +
              / \
             +  a_2
            / \
          a_0 a_1
      
      Traversing this tree during compilation can cause a stack overflow when n is
      large.
      
      Instead, for left-associate operations such as add, we now build up an
      n-ary node in the parse tree, of the form
      
               n-ary +
             /  |      \
            /   |  ...  \
          a_0  a_1      a_n
      
      The bytecode compiler can now iterate through the child expressions
      rather than recursing.
      
      This patch only supports arithmetic operations -- subsequent patches
      will enable the same optimization for logical tests and comma
      expressions.
      
      Bug: v8:6964
      Bug: chromium:724961
      Bug: chromium:731861
      Bug: chromium:752081
      Bug: chromium:771653
      Bug: chromium:777302
      Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
      Reviewed-on: https://chromium-review.googlesource.com/733120
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48920}
      52ef2a1c
  8. 19 Oct, 2017 1 commit
  9. 27 Jul, 2017 1 commit
  10. 25 Jul, 2017 1 commit
  11. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored
      This reverts commit a2fcdc7c.
      
      Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
      
      Original change's description:
      > [runtime] Move profiler ticks from SFI to feedback vector
      > 
      > Instead of counting profiler ticks on the shared function info (which is
      > shared between native contexts), count them on the feedback vector
      > (which is not). This allows us to continue pushing optimization
      > decisions off the SFI, onto the feedback vector.
      > 
      > Note that a side-effect of this is that ICs don't have to walk the stack
      > to reset profiler ticks, as they can access the feedback vector directly
      > from their feedback nexus.
      > 
      > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
      > Reviewed-on: https://chromium-review.googlesource.com/544888
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46411}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
      Reviewed-on: https://chromium-review.googlesource.com/574227
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  12. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  13. 12 Jul, 2017 1 commit
  14. 07 Jul, 2017 1 commit
  15. 05 Jul, 2017 1 commit
  16. 27 Jun, 2017 2 commits
  17. 22 May, 2017 1 commit