1. 15 Mar, 2018 1 commit
  2. 05 Mar, 2018 1 commit
  3. 02 Mar, 2018 1 commit
  4. 21 Feb, 2018 1 commit
  5. 16 Feb, 2018 1 commit
  6. 06 Feb, 2018 1 commit
  7. 24 Jan, 2018 1 commit
  8. 23 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] Single-switch generator bytecode · c869d40d
      Leszek Swirski authored
      Currently, yields and awaits inside loops compile to bytecode which
      switches to the top of the loop header, and switch again once inside the
      loop. This is to make loops reducible.
      
      This replaces this switching logic with a single switch bytecode that
      directly jumps to the bytecode being resumed. Among other things, this
      allows us to no longer maintain the generator state after the switch at
      the top of the function, and avoid having to track loop suspend counts.
      
      TurboFan still needs to have reducible loops, so we now insert loop
      header switches during bytecode graph building, for suspends that are
      discovered to be inside loops during bytecode analysis. We do, however,
      do some environment magic across loop headers since we know that we will
      continue switching if and only if we reached that loop header via a
      generator resume. This allows us to generate fewer phis and tighten
      liveness.
      
      Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
      Reviewed-on: https://chromium-review.googlesource.com/866734
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50804}
      c869d40d
  9. 22 Jan, 2018 1 commit
  10. 11 Jan, 2018 2 commits
    • 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
    • Leszek Swirski's avatar
      [ignition] Change RestoreGeneratorRegisters to ResumeGenerator · 713eb9e7
      Leszek Swirski authored
      This makes RestoreGeneratorRegisters do a fuller resume process: update
      the state register to indicate that it is now executing, and update the
      accumulator with the input_or_debug_pos of the generator - i.e., perform
      the boilerplate generator resuming in one bytecode instead of several.
      
      Change-Id: Ia87b6766ac023064b40d3e9a143e7b32118ea3a0
      Reviewed-on: https://chromium-review.googlesource.com/859770
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50499}
      713eb9e7
  11. 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
  12. 08 Jan, 2018 1 commit
  13. 04 Jan, 2018 2 commits
  14. 28 Nov, 2017 1 commit
  15. 07 Nov, 2017 1 commit
  16. 31 Oct, 2017 1 commit
    • Mathias Bynens's avatar
      [parser] Improve error message for `import()` · dbcea115
      Mathias Bynens authored
      Currently, dynamic `import()` throws the following SyntaxError when
      used without a specifier:
      
          > import();
          < Uncaught SyntaxError: Unexpected token )
      
      From the error message, it seems this the result of the code snippet
      being seen as static `import` followed by parens, as opposed to
      `import()` with no specifier.
      
      This patch makes this error message more clear:
      
          > import();
          < SyntaxError: import() requires a specifier
      
      BUG=v8:7020,v8:6513
      
      Change-Id: I3519dfd0029f38d23da858a5499f1d226e794935
      Reviewed-on: https://chromium-review.googlesource.com/747141Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49058}
      dbcea115
  17. 27 Oct, 2017 1 commit
  18. 25 Oct, 2017 1 commit
  19. 19 Oct, 2017 1 commit
  20. 13 Oct, 2017 1 commit
  21. 11 Oct, 2017 1 commit
  22. 10 Oct, 2017 1 commit
  23. 09 Oct, 2017 3 commits
  24. 05 Oct, 2017 3 commits
  25. 26 Sep, 2017 1 commit
  26. 15 Sep, 2017 1 commit
  27. 08 Sep, 2017 1 commit
  28. 25 Aug, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Always write the deferred command result register · e5df5bd0
      Leszek Swirski authored
      For deferred commands (such as in try-finally), some deferred commands
      save and restore the accumulator using a result register (e.g. return,
      throw, rethrow), while others don't (e.g. break, continue,
      fall-through).
      
      However, conditionally reading this result register that may not ever be
      written caused it to be considered live from the start of the function,
      as far as the liveness analysis could statically tell.
      
      Now, we write the result register for all deferred commands, including
      the fall-through. As a micro-optimization, we re-use the Smi command
      tokeen to clobber the result, rather than emitting an LdaUndefined.
      
      Bug: chromium:758472
      Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b
      Reviewed-on: https://chromium-review.googlesource.com/635592
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47612}
      e5df5bd0
  29. 11 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Interpreter] Remove new.target from fixed frame slot. · c820b89b
      Ross McIlroy authored
      Removes the new.target slot from the interpreter's fixed frame. Instead
      adds a field to BytecodeArray to get the bytecode's incoming
      new.target or generator object register. The InterpreterEntryTrampoline
      then sets this register with the incoming new.target (or generator object)
      when the function is called. This register can be directly the new.target
      or generator object variable if they are LOCAL location, otherwise it is a
      temporary register which is then moved to the variable's location during the
      function prologue.
      
      This fixes a hack in the deoptimizer where we would set the new.target fixed
      slot to undefined in order to avoid extending it's lifetime through the
      optimized code - now it's just a standard register and can be optimized away
      as normal.
      
      Bug=v8:6644
      
      Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
      Reviewed-on: https://chromium-review.googlesource.com/608966
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47320}
      c820b89b
    • Ross McIlroy's avatar
      [fullcodegen] Delete FullCodegen. · 1458e8b0
      Ross McIlroy authored
      Deletes the now unused Full-codegen compiler. Also removes some macro
      assembler instructions which are no longer used.
      
      Note: there is still additional cleanup work to do after this lands
      (e.g., remove support for FCG frames support and FCG
      debugger support, etc.), but this will be done in followup CLs to keep
      this patch managable.
      
      BUG=v8:6409
      
      Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
      Reviewed-on: https://chromium-review.googlesource.com/584773
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47307}
      1458e8b0
  30. 09 Aug, 2017 1 commit
  31. 02 Aug, 2017 1 commit
  32. 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