1. 29 Sep, 2017 1 commit
  2. 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
  3. 05 Sep, 2017 2 commits
  4. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  5. 23 Aug, 2017 1 commit
  6. 07 Aug, 2017 3 commits
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored
      Drop the deprecated CallConstructStub and remove the use of CallICStub
      from fullcodegen, since that feedback is unused completely every since
      Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      from fullcodegen nowadays, and completely nuke the CallICStub and the
      CallICTrampolineStub now (we can also transitively nuke the unused
      CreateAllocationSiteStub and CreateWeakCellStub).
      
      Instead the CallIC logic is integrated into Ignition now, and part of
      the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      follow-up cleanup with the way the Array constructor feedback is
      integrated, but that's way easier now.
      
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
      Reviewed-on: https://chromium-review.googlesource.com/603609
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31
    • Michael Achenbach's avatar
      Revert "[ic] Properly integrate the CallIC into Ignition." · 018128a4
      Michael Achenbach authored
      This reverts commit 6c541561.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240
      
      Original change's description:
      > [ic] Properly integrate the CallIC into Ignition.
      > 
      > Drop the deprecated CallConstructStub and remove the use of CallICStub
      > from fullcodegen, since that feedback is unused completely every since
      > Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      > from fullcodegen nowadays, and completely nuke the CallICStub and the
      > CallICTrampolineStub now (we can also transitively nuke the unused
      > CreateAllocationSiteStub and CreateWeakCellStub).
      > 
      > Instead the CallIC logic is integrated into Ignition now, and part of
      > the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      > follow-up cleanup with the way the Array constructor feedback is
      > integrated, but that's way easier now.
      > 
      > Bug: v8:5517, v8:6399, v8:6409, v8:6679
      > Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
      > Reviewed-on: https://chromium-review.googlesource.com/602134
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47192}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
      
      Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47193}
      018128a4
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · 6c541561
      Benedikt Meurer authored
      Drop the deprecated CallConstructStub and remove the use of CallICStub
      from fullcodegen, since that feedback is unused completely every since
      Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      from fullcodegen nowadays, and completely nuke the CallICStub and the
      CallICTrampolineStub now (we can also transitively nuke the unused
      CreateAllocationSiteStub and CreateWeakCellStub).
      
      Instead the CallIC logic is integrated into Ignition now, and part of
      the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      follow-up cleanup with the way the Array constructor feedback is
      integrated, but that's way easier now.
      
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
      Reviewed-on: https://chromium-review.googlesource.com/602134
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47192}
      6c541561
  7. 13 Jul, 2017 1 commit
  8. 05 Jul, 2017 1 commit
  9. 22 Jun, 2017 1 commit
  10. 20 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSCallWithArrayLike operator. · 767ce788
      bmeurer authored
      Add a new JSCallWithArrayLike operator that is backed by the
      CallWithArrayLike builtin, and use that operator for both
      Function.prototype.apply and Reflect.apply inlining. Also unify
      the handling of JSCallWithArrayLike and JSCallWithSpread in
      the JSCallReducer to reduce the copy&paste overhead.
      
      Drive-by-fix: Add a lot of test coverage for Reflect.apply and
      Function.prototype.apply in optimized code, especially for some
      corner cases, which was missing so far.
      
      BUG=v8:4587,v8:5269
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2950773002
      Cr-Commit-Position: refs/heads/master@{#46041}
      767ce788
  11. 19 Jun, 2017 1 commit
  12. 12 Jun, 2017 1 commit
  13. 08 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Start refactoring the Apply builtin. · af76779a
      bmeurer authored
      This splits the monolithic Apply builtin into several smaller builtins,
      namely CallVargargs and ConstructVarargs, which accept a length and a
      FixedArray of elements and deal with the actual stack manipulation, and
      CallWithArrayLike / ConstructWithArrayLike that deal with getting the
      elements from the receiver (for Function.prototype.apply, Reflect.apply
      and Reflect.construct), which can now be written using the CSA.
      
      The idea is that these builtins can be reused by TurboFan directly in
      the future when we optimize apply better, and that we can also reuse the
      core logic in the handling of spread calls/constructs.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2930623002
      Cr-Commit-Position: refs/heads/master@{#45794}
      af76779a
  14. 31 May, 2017 1 commit
  15. 18 May, 2017 2 commits
  16. 17 May, 2017 1 commit
  17. 05 May, 2017 1 commit
  18. 29 Apr, 2017 5 commits
  19. 21 Apr, 2017 5 commits
  20. 11 Apr, 2017 2 commits
  21. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored
      Adds a collection of call bytecodes which have an implicit undefined
      receiver argument, for cases such as global calls where we know that the
      receiver has to be undefined. This way we can skip an LdaUndefined,
      decrease bytecode register pressure, and set a more accurate
      ConvertReceiverMode on the interpreter and TurboFan call.
      
      As a side effect, the "normal" Call bytecode now becomes a rare case
      (only with calls and super property calls), so we get rid of its 0-2
      argument special cases and modify CallProperty[N] to use the
      NotNullOrUndefined ConvertReceiverMode.
      
      Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
      Reviewed-on: https://chromium-review.googlesource.com/463287
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  22. 29 Mar, 2017 2 commits
    • Caitlin Potter's avatar
      [cleanup] combine 3 ResumeGenerator stubs into one · 5615e5b8
      Caitlin Potter authored
      This hopefully shrinks binary size a bit, at the cost of (slightly)
      increasing the complexity of the ResumeGenerator stub. Includes ia32,
      x64, mips, mips64, arm and arm64 ports.
      
      BUG=v8:5855
      R=rmcilroy@chromium.org, paul.lind@imgtec.com, bmeurer@chromium.org, neis@chromium.org
      
      Change-Id: I848ce08afd828091a11e03c89d5be065ff557ef3
      Reviewed-on: https://chromium-review.googlesource.com/461303
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44244}
      5615e5b8
    • Caitlin Potter's avatar
      [async-iteration] implement AsyncGenerator · bf463c4d
      Caitlin Potter authored
      - Introduce new struct AsyncGeneratorRequest, which holds
        information pertinent to resuming execution of an
        AsyncGenerator, such as the Promise associated with the async
        generator request. It is intended to be used as a singly
        linked list, and holds a pointer to the next item in te queue.
      
      - Introduce JSAsyncGeneratorObject (subclass of
        JSGeneratorObject), which includes several new internal fields
        (`queue` which contains a singly linked list of
        AsyncGeneratorRequest objects, and `await_input` which
        contains the sent value from an Await expression (This is
        necessary to prevent function.sent (used by yield*) from
        having the sent value observably overwritten during
        execution).
      
      - Modify SuspendGenerator to accept a set of Flags, which
        indicate whether the suspend is for a Yield or Await, and
        whether it takes place on an async generator or ES6
        generator.
      
      - Introduce interpreter intrinsics and TF intrinsic lowering for
        accessing the await input of an async generator
      
      - Modify the JSGeneratorStore operator to understand whether or
        not it's suspending for a normal yield, or an AsyncGenerator
        Await. This ensures appropriate registers are stored.
      
      - Add versions of ResumeGeneratorTrampoline which store the
        input value in a different field depending on wether it's an
        AsyncGenerator Await resume, or an ordinary resume. Also modifies
        whether debug code will assert that the generator object is a
        JSGeneratorObject or a JSAsyncGeneratorObject depending on the
        resume type.
      
      BUG=v8:5855
      R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
      littledan@chromium.org, neis@chromium.org
      TBR=marja@chromium.org
      
      Change-Id: I9d58df1d344465fc937fe7eed322424204497187
      Reviewed-on: https://chromium-review.googlesource.com/446961
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44240}
      bf463c4d
  23. 24 Mar, 2017 3 commits
  24. 21 Mar, 2017 1 commit