1. 07 Dec, 2018 3 commits
  2. 05 Dec, 2018 1 commit
  3. 22 Nov, 2018 1 commit
  4. 19 Nov, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Move several IC stubs to builtins · 33da7197
      Jakob Gruber authored
      KeyedLoadSloppyArguments -> KeyedLoadIC_SloppyArguments
      KeyedStoreSloppyArguments -> KeyedStoreIC_SloppyArguments
      LoadIndexedIntercepter -> LoadIndexedInterceptorIC
      StoreInArrayLiteralSlowStub -> StoreInArrayLiteralIC_Slow
      StoreInterceptor -> StoreInterceptorIC
      StoreSlowElementStub -> KeyedStoreIC_Slow
      
      A few Store stubs were parameterized for the sole purpose of
      determining the KeyedAccessStoreMode later on. These are now
      implemented as a dedicated builtin for each store mode.
      
      Bug: v8:7777
      Change-Id: I743474b0e6c5d6ec2513bb9f8f3a93c5c0535927
      Reviewed-on: https://chromium-review.googlesource.com/c/1339859Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57592}
      33da7197
  5. 13 Sep, 2018 1 commit
  6. 17 Aug, 2018 1 commit
  7. 22 Jun, 2018 1 commit
  8. 29 May, 2018 2 commits
  9. 25 May, 2018 2 commits
  10. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  11. 14 Dec, 2017 1 commit
  12. 13 Dec, 2017 1 commit
  13. 20 Nov, 2017 1 commit
  14. 06 Nov, 2017 1 commit
  15. 25 Oct, 2017 1 commit
  16. 24 Oct, 2017 1 commit
    • Daniel Clifford's avatar
      Reimplement Array.prototype.slice in CSA and C++ · 6452b26a
      Daniel Clifford authored
      Previously, V8's slice was implemented in a combination of C++ and a 
      Javascript fallback. The disadvantage of this approach was that the
      fast-path required a call through the CEntryStub, which introduced
      considerable overhead for small arrays with fast elements kinds.
      
      Now the implementation primarily uses the CSA to generate both the
      full spec-complaint implementation as well as fast paths for argument
      objects and arrays with fast elements kinds. The CSA implementation
      uses a C++ implementation fallback in select situations where the the
      complexity of a CSA implementation would be too great and the
      CEntryStub overhead is not decisive (e.g. slices of dictionary
      elements arrays).
      
      Performance results on semi-random arrays with small number of
      elements (old vs. new):
      
      smi copy: 48.7 ms vs. 12 ms
      smi slice: 43.5 ms 14.8 ms
      object copy: 35.5 ms 7.7 ms
      object slice: 38.7 ms 8.8 ms
      dictionary slice: 2398.3 ms vs. 5.4 ms
      fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
      slow sloppy arguments slice: 28.9 ms vs. 8.5 ms
      
      As a bonus, the new implementation is fully spec-compliant and fixes
      at least one existing bug.
      
      The design document for Array.prototype builtin rework can be found
      at https://goo.gl/wFHe2n
      
      Bug: v8:1956,v8:6601,v8:6710,v8:6978
      Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
      Reviewed-on: https://chromium-review.googlesource.com/574710
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48853}
      6452b26a
  17. 20 Oct, 2017 1 commit
  18. 18 Oct, 2017 1 commit
  19. 29 Sep, 2017 1 commit
  20. 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
  21. 05 Sep, 2017 2 commits
  22. 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
  23. 23 Aug, 2017 1 commit
  24. 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
  25. 13 Jul, 2017 1 commit
  26. 05 Jul, 2017 1 commit
  27. 22 Jun, 2017 1 commit
  28. 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
  29. 19 Jun, 2017 1 commit
  30. 12 Jun, 2017 1 commit
  31. 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
  32. 31 May, 2017 1 commit
  33. 18 May, 2017 1 commit