1. 10 Feb, 2020 1 commit
  2. 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
  3. 19 Oct, 2017 1 commit
  4. 12 Oct, 2017 1 commit
  5. 12 Sep, 2017 1 commit
  6. 27 Jul, 2017 1 commit
  7. 25 Jul, 2017 1 commit
  8. 18 Jul, 2017 1 commit
  9. 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
  10. 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
  11. 05 Jul, 2017 1 commit
  12. 30 May, 2017 1 commit
    • Aleksey Kozyatinskiy's avatar
      [inspector] moved var initialization break location before init expression (reland) · fb6a094d
      Aleksey Kozyatinskiy authored
      This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      Benefits (see test for details):
       - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
       - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
       
      TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294
      Reviewed-on: https://chromium-review.googlesource.com/518116
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45598}
      fb6a094d
  13. 29 May, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[inspector] moved var initialization break location before init expression" · ee1db48c
      Michael Achenbach authored
      This reverts commit 7a9cc704.
      
      Reason for revert: Changes layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882
      
      This is about:
      inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html
      
      Original change's description:
      > [inspector] moved var initialization break location before init expression
      > 
      > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      > Benefits (see test for details):
      > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
      > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
      > 
      > Bug: v8:5909
      > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
      > Reviewed-on: https://chromium-review.googlesource.com/513926
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45530}
      
      TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f
      Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45547}
      ee1db48c
  14. 25 May, 2017 1 commit
  15. 10 May, 2017 1 commit
  16. 08 May, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      Ross McIlroy authored
      This reverts commit 662aa425.
      
      Reason for revert: Crashing on Canary
      BUG=chromium:718891
      
      Original change's description:
      > Reland: [TypeFeedbackVector] Store optimized code in the vector
      > 
      > Since the feedback vector is itself a native context structure, why
      > not store optimized code for a function in there rather than in
      > a map from native context to code? This allows us to get rid of
      > the optimized code map in the SharedFunctionInfo, saving a pointer,
      > and making lookup of any optimized code quicker.
      > 
      > Original patch by Michael Stanton <mvstanton@chromium.org>
      > 
      > BUG=v8:6246
      > TBR=yangguo@chromium.org,ulan@chromium.org
      > 
      > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      > Reviewed-on: https://chromium-review.googlesource.com/494487
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45084}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6246
      
      Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
      Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
  17. 04 May, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      Ross McIlroy authored
      Since the feedback vector is itself a native context structure, why
      not store optimized code for a function in there rather than in
      a map from native context to code? This allows us to get rid of
      the optimized code map in the SharedFunctionInfo, saving a pointer,
      and making lookup of any optimized code quicker.
      
      Original patch by Michael Stanton <mvstanton@chromium.org>
      
      BUG=v8:6246
      TBR=yangguo@chromium.org,ulan@chromium.org
      
      Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  18. 02 May, 2017 2 commits
  19. 10 Apr, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" · 496864f8
      Ross McIlroy authored
      This relands commit d3e9aade. The original CL was reverted speculatively but didn't cause the buildbot failure.
      
      Original change's description:
      > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
      > 
      > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
      > literals in the BytecodeGenerator. This enables us to perform the
      > transformation for literals on either side for commutative operations, and
      > Avoids having to do the check on every bytecode in the peephole optimizer.
      > 
      > In the process, adds Smi bytecode variants for all binary operations, adding
      >  - MulSmi
      >  - DivSmi
      >  - ModSmi
      >  - BitwiseXorSmi
      >  - ShiftRightLogical
      > 
      > BUG=v8:6194
      > 
      > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
      > Reviewed-on: https://chromium-review.googlesource.com/466246
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#44477}
      
      TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6194
      
      Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8
      Reviewed-on: https://chromium-review.googlesource.com/472746Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44511}
      496864f8
  20. 07 Apr, 2017 2 commits
  21. 06 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Collect and use type feedback on ToNumber. · dd7ce93c
      bmeurer authored
      Make Ignition collect BinaryOperationFeedback on ToNumber, using the
      shared type feedback slot with the following Inc/Dec bytecode, and use
      this feedback in TurboFan to turn the ToNumber(x) operation into a
      SpeculativeNumberMultiply(x,1) with the feedback hint.
      
      R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
      BUG=v8:6214,v8:5267
      
      Review-Url: https://codereview.chromium.org/2804813003
      Cr-Commit-Position: refs/heads/master@{#44440}
      dd7ce93c
  22. 25 Jan, 2017 1 commit
  23. 08 Dec, 2016 1 commit
  24. 08 Nov, 2016 1 commit
  25. 04 Oct, 2016 1 commit
  26. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored
      There are only a few occasions where we allocate a register in an outer
      expression allocation scope, which makes the costly free-list approach
      of the BytecodeRegisterAllocator unecessary. This CL replaces all
      occurrences with moves to the accumulator and stores to a register
      allocated in the correct scope. By doing this, we can simplify the
      BytecodeRegisterAllocator to be a simple bump-pointer allocator
      with registers released in the same order as allocated.
      
      The following changes are also made:
       - Make BytecodeRegisterOptimizer able to use registers which have been
         unallocated, but not yet reused
       - Remove RegisterExpressionResultScope and rename
         AccumulatorExpressionResultScope to ValueExpressionResultScope
       - Introduce RegisterList to represent consecutive register
         allocations, and use this for operands to call bytecodes.
      
      By avoiding the free-list handling, this gives another couple of
      percent on CodeLoad.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2369873002
      Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  27. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored
      Add a notion of "invocation count" to the baseline compilers, which
      increment a special slot in the TypeFeedbackVector for each invocation
      of a given function (the optimized code doesn't currently collect this
      information).
      
      Use this invocation count to relativize the call counts on the call
      sites within the function, so that the inlining heuristic has a view
      of relative importance of a call site rather than some absolute numbers
      with unclear meaning for the current function. Also apply the call site
      frequency as a factor to all frequencies in the inlinee by passing this
      to the graph builders so that the importance of a call site in an
      inlinee is relative to the topmost optimized function.
      
      Note that all functions that neither have literals nor need type
      feedback slots will share a single invocation count cell in the
      canonical empty type feedback vector, so their invocation count is
      meaningless, but that doesn't matter since we only use the invocation
      count to relativize call counts within the function, which we only have
      if we have at least one type feedback vector (the CallIC slot).
      
      See the design document for additional details on this change:
      https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
      
      BUG=v8:5267,v8:5372
      R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2337123003
      Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36
  28. 06 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Remove constant pool type in tests · b28b7e13
      leszeks authored
      For historical reasons, the interpreter's bytecode expectations tests
      required a type for the constant pool. This had two disadvantages:
      
       1. Strings and numbers were not visible in mixed pools, and
       2. Mismatches of pool types (e.g. when rebaselining) would cause parser
          errors
      
      This removes the pool types, making everything 'mixed', but appending
      the values to string and number valued constants. Specifying a pool type
      in the *.golden header now prints a warning (for backwards compatibility).
      
      BUG=v8:5350
      
      Review-Url: https://codereview.chromium.org/2310103002
      Cr-Commit-Position: refs/heads/master@{#39216}
      b28b7e13
  29. 23 Aug, 2016 1 commit
  30. 08 Aug, 2016 1 commit
  31. 27 Jul, 2016 1 commit
  32. 22 Jul, 2016 1 commit
  33. 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
  34. 09 Jun, 2016 1 commit
  35. 27 May, 2016 1 commit
  36. 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
  37. 11 May, 2016 1 commit
  38. 22 Apr, 2016 1 commit