1. 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
  2. 19 Oct, 2017 1 commit
  3. 27 Jul, 2017 1 commit
  4. 25 Jul, 2017 1 commit
  5. 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
  6. 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
  7. 12 Jul, 2017 1 commit
  8. 07 Jul, 2017 1 commit
  9. 05 Jul, 2017 1 commit
  10. 27 Jun, 2017 2 commits
  11. 22 May, 2017 1 commit