1. 27 Nov, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored
      Previously, the class fields initializer function was stored on a
      synthetic context allocated variable. This approach had sevaral
      problems:
      
      - We didn't know that class literal had fields until after we had
      completely parsed the class literal. This meant that we had to go back
      and fix up the scope of the constructor to have this synthetic
      variable. This resulted in mismatch between parser and preparsed scope
      data.
      
      - This synthetic variable could potentially resolve to an initializer
      of an outer class.
      
      For ex:
      class X extends Object {
        c = 1;
        constructor() {
          var t = () => {
            class P extends Object {
              constructor() {
                var t = () => { super(); };
                t();
              }
            }
            super();
          }
          t();
        }
      }
      
      In this the inner class P could access the outer class X's initiliazer
      function. We would have to maintain extra metadata to make sure this
      doesn't happen.
      
      Instead this new approach uses a private symbol to store the
      initializer function on the class constructor itself.
      
      For the base constructor case, we can simply check for a bit on the
      constructor function literal to see if we need to emit code that loads
      and calls this initializer function. Therefore, we don't pay the cost
      of loading this function in case there are no class fields.
      
      For the derived constructor case, there are two possiblities:
      (a) We are in a super() call directly in the derived constructor:
      
      In this case we can do a check similar to the base constructor check,
      we can check for a bit on the derived constructor and emit code for
      loading and calling the initializer function.
      
      This is usually the common case and we don't pay any cost for not using
      class fields.
      
      (b) We are in a super() call inside an arrow function in the derived
      constructor:
      
      In this case, we /always/ emit code to load and call the initializer
      function. If the function doesn't exist then we have undefined and we
      don't call anything. Otherwise we call the function.
      
      super() can't be called twice so even if we emit code to load and call
      the initializer function multiple times, it doesn't matter because it
      would have already been an error.
      
      Bug: v8:5367
      Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
      Reviewed-on: https://chromium-review.googlesource.com/781660
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  2. 16 Nov, 2017 1 commit
  3. 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
  4. 03 Nov, 2017 2 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
  5. 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
  6. 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
  7. 23 Oct, 2017 1 commit
  8. 19 Oct, 2017 1 commit
  9. 16 Oct, 2017 1 commit
  10. 13 Oct, 2017 1 commit
  11. 05 Oct, 2017 2 commits
  12. 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
  13. 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
  14. 16 Aug, 2017 1 commit
  15. 01 Aug, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Provide better error when destructuring callable · c805d5e3
      Sathya Gunasekaran authored
      The patch changes CallPrinter's AST traversal to continue even after
      the first positive match for an AST node. This helps us check for the
      subsequent GetIterator AST node in case of destructuring.
      
      We can not differentiate between the function call failing and the
      GetIterator failing based on source position info. This would involve
      runtime checks costing performance.
      
      Instead of providing an incorrect error, we provide both the
      possiblities to user and allow them to disambiguate.
      
      Previously,
        d8> function f() { return 5; }
        undefined
        d8> var [a] = f();
        (d8):1: TypeError: f is not a function
        var [a] = f();
                  ^
        TypeError: f is not a function
            at (d8):1:11
      
      
      Now,
        d8> function f() { return 5; }
        undefined
        d8> var [a] = f();
        (d8):1: TypeError: f is not a function or its return value is not iterable
        var [a] = f();
                  ^
        TypeError: f is not a function or its return value is not iterable
            at (d8):1:11
      
      Bug: v8:6616, v8:6513
      Change-Id: I3d6427f10cae54951b0ad0e5ddcbe802bb7191c1
      Reviewed-on: https://chromium-review.googlesource.com/594894
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47025}
      c805d5e3
  16. 14 Jul, 2017 3 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
    • Michael Starzinger's avatar
      [ast] Actually print the try-block in AstPrinter. · afdb0b45
      Michael Starzinger authored
      This fixes a refactoring bug in the AstPrinter to actually print the
      try-block of {TryCatchStatement} and {TryFinallyStatement} nodes.
      
      R=neis@chromium.org
      
      Change-Id: I6448251c1eed3f85100902592a76dc7d3a614334
      Reviewed-on: https://chromium-review.googlesource.com/571748Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46670}
      afdb0b45
    • 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
  17. 13 Jul, 2017 1 commit
  18. 10 Jul, 2017 1 commit
  19. 06 Jul, 2017 1 commit
  20. 05 Jul, 2017 1 commit
  21. 23 Jun, 2017 1 commit
  22. 06 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored
      Properly propagate the fact that the function has a statically known name from
      parser to SharedFunctionInfo objects. The empty string that has been set as
      name before this CL does not help to distinguish cases like:
        var o1 = { ''(){} };
        var o1 = { [foo()](){} };
      or
        var o2 = { get ''(){} };
        var o2 = { get [foo()](){} };
      
      This is a preliminary step for using different layouts for closure objects with
      and without computed names.
      
      TBR=bmeurer@chromium.org, marja@chromium.org
      
      Bug: v8:6459
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
      Reviewed-on: https://chromium-review.googlesource.com/522073
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
  23. 11 Apr, 2017 2 commits
    • 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
    • Caitlin Potter's avatar
      [prettyprinter] improve call-printing of GetIterator nodes · b086856f
      Caitlin Potter authored
      Fix error message printed by Runtime_ThrowCalledNonCallable.
      
      As noted on the bug, this has a slight problem in that it will always
      print that "asyncIterator" was not callable for GetIterator with an
      async IteratorType, though it may be referring to a different call.
      This issue is present regardless of the change I introduced to perform
      this desugaring in the BytecodeGenerator.
      
      BUG=v8:6187
      R=adamk@chromium.org, verwaest@chromium.org
      
      Change-Id: I2077b7cd5976d9d9ba044f0dff44ee8c312d1263
      Reviewed-on: https://chromium-review.googlesource.com/470806Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#44543}
      b086856f
  24. 05 Apr, 2017 1 commit
  25. 04 Apr, 2017 1 commit
  26. 31 Mar, 2017 1 commit
  27. 22 Mar, 2017 1 commit
  28. 03 Mar, 2017 1 commit
  29. 07 Feb, 2017 1 commit
  30. 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
  31. 09 Jan, 2017 1 commit
  32. 05 Jan, 2017 1 commit
    • gsathya's avatar
      [ESnext] Implement Object spread · a40b7172
      gsathya authored
      This patch adds parsing of spread object property.
      
      -- Changes ParsePropertyName to parse Token::ELLIPSIS.
      -- Throws if rest is encountered by setting a pattern error.
      -- Adds a new PropertyKind enum (SPREAD)
      -- Adds a new ObjectLiteralProperty::kind (SPREAD)
      -- Adds a new harmony-object-spread flag and protects the parser code
      with it.
      -- Adds a new runtime function called CopyDataProperties
      -- Does not add any support for this feature in fullcodegen.
      -- Ignition calls out to a runtime function CopyDataProperties to
      perform spread operation.
      -- Move FastAssign from builtins-objects.cc to objects.cc
      -- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties
      
      Object rest will be implemented in a follow on patch.
      
      BUG=v8:5549
      
      Review-Url: https://codereview.chromium.org/2606833002
      Cr-Commit-Position: refs/heads/master@{#42102}
      a40b7172
  33. 19 Dec, 2016 3 commits