1. 31 Oct, 2017 4 commits
  2. 27 Oct, 2017 2 commits
  3. 25 Oct, 2017 2 commits
    • Adam Klein's avatar
      [ast] Avoid unnecessary creation of Literals in TemplateString handling · 43095278
      Adam Klein authored
      For the tagged case, we never use the Literal AST node, so don't bother
      creating them in the first place. Instead, store AstRawStrings directly,
      and only wrap with Literals when desugaring untagged templates into
      binary ops.
      
      This also makes the upcoming merge of Literal and AstValue simpler.
      
      Bug: v8:6984
      Change-Id: I9f12710b05c6d63d7e91f2707cd08093f7ff3f11
      Reviewed-on: https://chromium-review.googlesource.com/736151Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48940}
      43095278
    • 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
  4. 24 Oct, 2017 1 commit
  5. 23 Oct, 2017 1 commit
  6. 19 Oct, 2017 1 commit
  7. 16 Oct, 2017 1 commit
  8. 13 Oct, 2017 4 commits
  9. 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
  10. 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
  11. 18 Sep, 2017 1 commit
  12. 13 Sep, 2017 1 commit
  13. 12 Sep, 2017 1 commit
  14. 07 Sep, 2017 1 commit
  15. 05 Sep, 2017 1 commit
  16. 31 Aug, 2017 2 commits
  17. 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
  18. 29 Aug, 2017 3 commits
  19. 25 Aug, 2017 1 commit
  20. 23 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored
      > This reverts commit 42d3d36b.
      > 
      > Original change's description:
      > > [Compiler] Remove code aging support.
      > > 
      > > Code aging is no longer supported by any remaining compilers now
      > > that full codegen has been removed. This CL removes all vestiges of
      > > code aging.
      > > 
      > > BUG=v8:6409
      > > 
      > > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > > Reviewed-on: https://chromium-review.googlesource.com/619153
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#47501}
      > 
      > TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      > 
      > Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6409
      > Reviewed-on: https://chromium-review.googlesource.com/625998
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47506}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
  21. 22 Aug, 2017 3 commits
  22. 21 Aug, 2017 1 commit
  23. 18 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Parsing] Remove parse-task support. · ef8baffa
      Ross McIlroy authored
      Parse tasks are not currently used, and will need to be changed significantly
      for background compilation, so we remove them for now.
      
      BUG=v8:6093,v8:5203
      
      Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745
      Reviewed-on: https://chromium-review.googlesource.com/617140
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47446}
      ef8baffa
    • Adam Klein's avatar
      [ast] Save one pointer in most Function and Variable declaration node · 69b165db
      Adam Klein authored
      Currently, Declaration stores a Scope pointer to whichever Scope the
      declaration appeared in. This is used to disallow var declarations
      being hoisted over lexical declarations. For example:
      
        {
          let x;
          { var x; }
        }
      
      But in fact this is the only sort of case where storing the scope
      is required: for lexical declarations (including function declarations
      appearing in blocks), Declaration::scope() was always identical to
      Declaration::proxy()->var()->scope(). That is, only var declarations
      end up "nested" in this way.
      
      This patch adds a subclass of VariableDeclaration to store the Scope.
      Since the only thing that cares about that data is Scope analysis,
      this isn't treated as a distinct AstNode::NodeType from VariableDeclaration,
      leaving all AstVisitors untouched in the process.
      
      Also reworked the logic in Scope::CheckConflictingVarDeclarations() for
      clarity after making changes to accomodate the new code.
      
      Change-Id: I6ee4298700508ab9e28a76ddb8504bae68bc473f
      Reviewed-on: https://chromium-review.googlesource.com/619595
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47441}
      69b165db
  24. 17 Aug, 2017 1 commit
  25. 16 Aug, 2017 1 commit
  26. 11 Aug, 2017 1 commit