1. 29 Jan, 2018 1 commit
  2. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  3. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  4. 18 Dec, 2017 1 commit
  5. 15 Dec, 2017 1 commit
  6. 17 Nov, 2017 1 commit
  7. 10 Nov, 2017 2 commits
  8. 09 Nov, 2017 1 commit
    • Ross McIlroy's avatar
      [Ast] Teach Ast Printer to print raw literal values. · ff4e4ab4
      Ross McIlroy authored
      Converts the ast prettyprinter to printing literals from the raw values
      rather than internalized on-heap strings. This enables ast printing before
      internalizing, and means we can avoid use of the isolate in the interpreter's
      off-thread phase.
      
      Also removes --print-builtin-ast and relies on just --print-ast to print
      everything.
      
      Finally, converts FunctionLiteral's debug_name function to return a
      char[] which is created from the raw name literal where it exists, rather
      than relying on the value having been internalized.
      
      BUG=v8:5203
      
      Change-Id: Ib69f754e254736f415db38713e6209465817e6f1
      Reviewed-on: https://chromium-review.googlesource.com/758681Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49276}
      ff4e4ab4
  9. 08 Nov, 2017 1 commit
  10. 03 Nov, 2017 3 commits
    • Ross McIlroy's avatar
      Revert "[Ast] Teach Ast Printer to print raw literal values." · 5dc02ef2
      Ross McIlroy authored
      This reverts commit c60934e9.
      
      Reason for revert: breaks nosnap build
      
      
      Original change's description:
      > [Ast] Teach Ast Printer to print raw literal values.
      > 
      > Converts the ast prettyprinter to printing literals from the raw values
      > rather than internalized on-heap strings. This enables ast printing before
      > internalizing, and means we can avoid use of the isolate in the interpreter's
      > off-thread phase.
      > 
      > Also removes --print-builtin-ast and relies on just --print-ast to print
      > everything.
      > 
      > Finally, converts FunctionLiteral's debug_name function to return a
      > char[] which is created from the raw name literal where it exists, rather
      > than relying on the value having been internalized.
      > 
      > BUG=v8:5203
      > 
      > Change-Id: I0e358d6acc9ae4516ed49e7a763e208fea5fcf66
      > Reviewed-on: https://chromium-review.googlesource.com/749261
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49119}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org
      
      Change-Id: Ic9d511f5107666a2f6a2bf59d8e93643c32d4d2b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5203
      Reviewed-on: https://chromium-review.googlesource.com/753627Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49120}
      5dc02ef2
    • Ross McIlroy's avatar
      [Ast] Teach Ast Printer to print raw literal values. · c60934e9
      Ross McIlroy authored
      Converts the ast prettyprinter to printing literals from the raw values
      rather than internalized on-heap strings. This enables ast printing before
      internalizing, and means we can avoid use of the isolate in the interpreter's
      off-thread phase.
      
      Also removes --print-builtin-ast and relies on just --print-ast to print
      everything.
      
      Finally, converts FunctionLiteral's debug_name function to return a
      char[] which is created from the raw name literal where it exists, rather
      than relying on the value having been internalized.
      
      BUG=v8:5203
      
      Change-Id: I0e358d6acc9ae4516ed49e7a763e208fea5fcf66
      Reviewed-on: https://chromium-review.googlesource.com/749261
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49119}
      c60934e9
    • Sathya Gunasekaran's avatar
      [class] Evaluate static computed props during class definition · 4f781eca
      Sathya Gunasekaran authored
      This patch evaluates computed properties in the order of declaration
      during class definition time.
      
      This patch creates a synthetic variable to store the result of
      evaluating a computed property and then looks this up in the
      initializer function.
      
      Bug: v8:5367
      Change-Id: I4182c6a01196d2538991818142890f6afb0e532b
      Reviewed-on: https://chromium-review.googlesource.com/752567Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49115}
      4f781eca
  11. 31 Oct, 2017 4 commits
  12. 27 Oct, 2017 1 commit
    • Adam Klein's avatar
      [ast] Move AstValue implementation into Literal · 317cf321
      Adam Klein authored
      This eliminates the AstValue class, effectively moving its
      implementation into the Literal AstNode. This should cause
      no difference in behavior, but it does signal some shifts
      in the underlying system. Biggest changes include:
      
        - Reduction in AST memory usage
        - No duplicate HeapNumbers in Ignition constant pools
        - Non-String values are allocated either at constant pool
          creation time (or at boilerplate creation time for literals),
          rather than at AstValueFactory::Internalize() time.
      
      There are a variety of test-only/debug-only changes due to these
      switches as well.
      
      Bug: v8:6984
      Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
      Reviewed-on: https://chromium-review.googlesource.com/731111
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49013}
      317cf321
  13. 25 Oct, 2017 1 commit
  14. 24 Oct, 2017 1 commit
  15. 19 Oct, 2017 1 commit
  16. 13 Oct, 2017 1 commit
  17. 10 Oct, 2017 1 commit
  18. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored
      When inlining based on SharedFunctionInfo rather than based on concrete
      JSFunction, we weren't able to properly optimize array, object and
      regexp literals inside the inlinee, because we didn't know the concrete
      FeedbackVector for the inlinee inside JSCreateLowering. This was because
      JSCreateLowering wasn't properly updated after the literals moved to the
      FeedbackVector. Now with this CL we also have the VectorSlotPair on the
      literal creation operators, just like we do for property accesses and
      calls, and are thus able to always access the appropriate FeedbackVector
      and optimize the literal creation.
      
      The impact is illustrated by the micro-benchmark on the tracking bug,
      which goes from
      
        createEmptyArrayLiteral: 1846 ms.
        createShallowArrayLiteral: 1868 ms.
        createShallowObjectLiteral: 2246 ms.
      
      to
      
        createEmptyArrayLiteral: 1175 ms.
        createShallowArrayLiteral: 1187 ms.
        createShallowObjectLiteral: 1195 ms.
      
      with this CL, so up to 2x faster now.
      
      Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
      and cleanup the names of the other builtins to be consistent with the
      names of the TurboFan operators and Ignition bytecodes.
      
      Bug: v8:6856
      Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
      Reviewed-on: https://chromium-review.googlesource.com/680656
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  19. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  20. 18 Sep, 2017 1 commit
  21. 13 Sep, 2017 1 commit
  22. 07 Sep, 2017 1 commit
  23. 05 Sep, 2017 1 commit
  24. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  25. 31 Aug, 2017 1 commit
  26. 30 Aug, 2017 1 commit
    • Adam Klein's avatar
      [ast] Make CaseClause a plain ZoneObject, not an Expression · de046f5f
      Adam Klein authored
      CaseClause never made sense as an Expression; this CL allows us to
      remove several UNREACHABLEs and slim down the representation of
      CaseClause by removing its source position (which was only used
      in prettyprinting).
      
      The only real fallout of this change is that SourceRangeMap now
      stores its keys as ZoneObject*, rather than AstNode*, but since
      there's already compile time typechecking for inserting items
      into the map this shouldn't cause any ill effects.
      
      While modifying CaseClause, also removed the dead body_target()
      accessor (and related member variable). Thus this CL overall
      reduces the memory needed for each CaseClause by two words.
      
      Bug: v8:6092
      Change-Id: I0021c0590a69e29305c41ec6105c8824ae0cc25b
      Reviewed-on: https://chromium-review.googlesource.com/639316Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47722}
      de046f5f
  27. 29 Aug, 2017 1 commit
  28. 18 Aug, 2017 1 commit
  29. 17 Aug, 2017 1 commit
  30. 16 Aug, 2017 1 commit
  31. 13 Jul, 2017 1 commit
  32. 12 Jul, 2017 2 commits