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. 24 Oct, 2017 1 commit
  3. 23 Oct, 2017 1 commit
  4. 16 Oct, 2017 1 commit
  5. 05 Oct, 2017 1 commit
  6. 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
  7. 07 Sep, 2017 1 commit
    • Marja Hölttä's avatar
      [parser] Fix arrow funcs w/ destructuring params again. [Alternative fix] · 138fbdb4
      Marja Hölttä authored
      What happened:
      - When rewriting in DoParseFunction, the relevant function scope is no longer in
      the scope stack.
      - The correct scope is given to the PatternRewriter.
      - PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
      - BuildIteratorCloseForCompletion would just call NewTemporary (which creates
      a new temporary in Parser's current scope) instead of using the scope passed to
      it and calling NewTemporary on it.
      - Normally this went unnoticed, since it doesn't matter that much where the
      temporary is.
      - But in the lazy arrow func case, the Parser's scope at that point was the
      already-resolved outer scope, and a DCHECK detected this problem.
      
      Kudos & thanks to verwaest@ for a debugging session :)
      
      BUG=chromium:761831
      
      Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
      Reviewed-on: https://chromium-review.googlesource.com/650297
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47877}
      138fbdb4
  8. 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
  9. 29 Aug, 2017 2 commits
  10. 22 Aug, 2017 1 commit
  11. 18 Aug, 2017 2 commits
    • 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
    • Adam Klein's avatar
      [pattern-rewriter] Handle already-rewritten RewritableExpressions as before · cec289ea
      Adam Klein authored
      Before 983eec89, RewritableExpressions
      which had been queued for destructuring assignment rewriting but which
      turned out to be part of a binding pattern in arrow function parameters
      would be silently ignored by the PatternRewriter. After that CL, they
      failed with a DCHECK.
      
      This patch reverts to the previous behavior, with a TODO to handle this
      in a better way by dequeuing RewritableExpressions that turned out
      to be part of an inner arrow function.
      
      Bug: chromium:756332
      Change-Id: I0a9bf51499940c944034d9a8128e89950de38059
      Reviewed-on: https://chromium-review.googlesource.com/619506Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47435}
      cec289ea
  12. 16 Aug, 2017 2 commits
  13. 10 Aug, 2017 1 commit
    • Adam Klein's avatar
      [parser] Move PatternRewriter declaration to pattern-rewriter.cc · 774c6413
      Adam Klein authored
      PatternRewriter is an implementation detail of the Parser; as such,
      there's no need for it to be exposed in parser.h (or even to most
      of the Parser). This patch is a cleanup that hides all of PatternRewriter
      in pattern-rewriter.cc, exposing only the few helper methods needed
      by the rest of Parser in parser.h.
      
      Also removed some duplication between the two PatternRewriter
      initialization functions by adding a constructor, and added
      a few DCHECKs here and there.
      
      Change-Id: I1dbae8dc0172ff16e40585d0e718d206d2075b3a
      Reviewed-on: https://chromium-review.googlesource.com/609365Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47291}
      774c6413
  14. 09 Aug, 2017 2 commits
  15. 31 Jul, 2017 1 commit
  16. 25 Jul, 2017 1 commit
  17. 14 Jul, 2017 2 commits
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored
      SuspendFlags was originally used by the suspend operation to determine
      which field to record the bytecode offset of a suspended generator, and
      the value the generator was resumed with. For async generators, await
      operations would use a separate field, in order to preserve the previous
      yield input value. This was important to ensure `function.sent`
      continued to function correctly.
      
      As function.sent is being retired, this allows the removal of support
      for that. Given that this was the only real need for SuspendFlags in the
      first place (with other uses tacked on as a hack), this involves several
      other changes as well:
      
      - Modification of MacroAssembler AssertGeneratorObject. No longer
        accepts a SuspendFlags parameter to determine which type of check to
        perform.
      - Removal of `flags` operand from SuspendGenerator bytecode, and the
        GeneratorStore js-operator.
      - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
      - Removal of Runtime functions, interpreter intrinsics and
        AccessBuilders associated with the [[await_input_or_debug_pos]] field
        in JSAsyncGeneratorObject, as this field no longer exists.
      - Addition of a new `Yield` AST node (subclass of Suspend) in order to
        prevent the need for the other SuspendFlag values.
      
      BUG=v8:5855
      TBR=bmeurer@chromium.org
      
      Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
      Reviewed-on: https://chromium-review.googlesource.com/570485
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
    • Caitlin Potter's avatar
      [async-await] desugar Await in BytecodeGenerator · 8b5b444a
      Caitlin Potter authored
      This includes several changes. From most to least interesting:
      
      - No longer implement AwaitExpressions using a do-expression.
      - Reduces frame-size of async generators by not allocating temporary
        variables to hold results of Await epxressions.
      - Streamline and reduce generated bytecodes for Await.
      - Debugger no longer emits a debug::kCallBreakLocation breakpoint for
      the JS-builtin call performed for Await, and instead only emits such
      a breakpoint if the operand of Await is actually a call.
      - Push fewer parameters to Await* builtins, using the receiver for the
        first parameter (possible now that the CallRuntime invocation not
        part of the AST).
      - Adds a new Await AST node. No new members or anything, but it seemed
        palatable to avoid having `if (is_await())` in a number of
        VisitSuspend functions.
      
      BUG=v8:5855, v8:5099, v8:4483
      R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
      TBR=bmeurer@chromium.org
      
      Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
      Reviewed-on: https://chromium-review.googlesource.com/558806
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46666}
      8b5b444a
  18. 06 Jul, 2017 1 commit
  19. 30 Jun, 2017 1 commit
  20. 23 Jun, 2017 1 commit
  21. 19 Jun, 2017 1 commit
  22. 15 Jun, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Better error message when destructuring against undefined/null · bc2c785c
      Sathya Gunasekaran authored
      Previously, when destructuring against null or undefined we would
      print:
      
        d8> var { x } = null
        (d8):1: TypeError: Cannot match against 'undefined' or 'null'.
        var { x } = null
        ^
        TypeError: Cannot match against 'undefined' or 'null'.
            at (d8):1:1
      
      
      The above message uses the term "match" which isn't a common term in
      JavaScript to describe destructuring. This message also doesn't
      provide the name of the property that fails destructuring.
      
      This patch changes the error message to be:
      
        d8> var { x } = null;
        (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
        var { x } = null;
              ^
        TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
            at (d8):1:1
      
      This patch changes the message to say "destructure" instead of "match".
      
      This patch adds support for printing property names that are string
      literals. We iterate through every property and pick the first string
      literal property name if it exists. This provides at least some
      feedback to the developer.
      
      This patch also makes the pointer point to the position of the
      property name that fails destructuring.
      
      For computed and numeric property names, we print a generic error:
        d8> var { 1: x } = null
        (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
        var { 1: x } = null
        ^
        TypeError: Cannot destructure against 'undefined' or 'null'.
            at (d8):1:1
      
      Bug: v8:6499
      Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
      Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45965}
      bc2c785c
  23. 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
  24. 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
  25. 25 May, 2017 1 commit
  26. 11 Apr, 2017 1 commit
    • gsathya's avatar
      [ESNext] Implement DynamicImportCall · 94283dcf
      gsathya authored
      This patch implements the runtime semantics of dynamic import.
      
      We create a new ASTNode so that we can pass the JSFunction closure() to
      the runtime function from which we get the script_url.
      
      d8 implements the embedder logic required to load and evaluate the modules.
      
      The API is mostly implemented as specified.
      
      BUG=8:5785
      
      Review-Url: https://codereview.chromium.org/2703563002
      Cr-Commit-Position: refs/heads/master@{#44551}
      94283dcf
  27. 22 Mar, 2017 1 commit
  28. 15 Feb, 2017 1 commit
  29. 10 Feb, 2017 1 commit
  30. 07 Feb, 2017 3 commits
  31. 01 Feb, 2017 1 commit
    • adamk's avatar
      [parser] Remove hoist_scope from DeclarationDescriptor · 59b8496c
      adamk authored
      The hoist_scope member of DeclarationDescriptor was only used to pass the function
      scope for declaration of parameters containing sloppy evals, for example:
      
        function f(x = eval("var y")) { }
      
      In cases like this, "x" is declared in the function scope but "y" is declared in an inner scope.
      Rather than passing the function scope as "hoist_scope", we simply ask for the outer_scope()
      of the inner scope as needed in PatternRewriter.
      
      This reduces the cognitive overhead of understanding what a DeclarationDescriptor has; for
      example, it removes some dead code from the PreParser which never has to deal
      with a situation like the example above.
      
      Review-Url: https://codereview.chromium.org/2662183002
      Cr-Commit-Position: refs/heads/master@{#42861}
      59b8496c
  32. 31 Jan, 2017 1 commit
  33. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64