1. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a CallFunctionTemplate builtin. · a2d9924c
      Benedikt Meurer authored
      When calling into API callbacks from TurboFan optimized, we can
      currently only take a fast-path when TurboFan is able to find some
      information about the receiver in the graph, or when the API callback
      specifies that it neither requires an access check (aka "accepts any
      receiver") nor an interface check (aka "compatible receiver check").
      
      This change introduces a new CallFunctionTemplate builtin that sits
      in front of the CallApiCallback builtin and does both the access as well
      as the interface check as necessary (and raises appropriate exceptions).
      This way TurboFan can still call into the API callback via the fast-path
      even without ahead knowledge about the receiver, which is significantly
      faster than the generic call machinery for API callbacks.
      
      On the test case from the Angular team[1], the interesting metrics
      improve from
      
        DOM_mono: 0.273 ms
        DOM_mega: 0.571 ms
        DOM_call: 0.649 ms
      
      to
      
        DOM_mono: 0.264 ms
        DOM_mega: 0.572 ms
        DOM_call: 0.368 ms
      
      so the DOM_call is only about **1.4 times slower** than the DOM_mono and
      about **1.5 times faster** than the DOM_mega case (compared to **2.4
      times slower**). Execution time in the DOM_call was reduced by around
      **~45%**.
      
      Currently this new code path is limited to TurboFan optimized code, but
      the idea is to eventually migrate the API calls from baseline to also
      use the new CSA functionality, but there are lot's of subleties to take
      into account, so starting with small changes to get coverage for the
      basic building blocks.
      
      [1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html
      
      Bug: v8:8820
      Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1470129
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59598}
      a2d9924c
  2. 13 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [builtins] Improve CallApiCallback calling convention. · c142e0a2
      Benedikt Meurer authored
      Refactor the CallApiCallback builtin to
      
      - pass the context as with other stubs, and
      - pass holder and call data in registers.
      
      This avoids having to place holder and call data onto the stack, and
      thus makes it possible to easily call the CallApiCallback builtin from
      other builtins while just forwarding the (stack) arguments. The idea
      is to use this in the future to optimize the general case of calling
      into any API method via a FunctionTemplateInfo and doing appropriate
      security and/or interface checks upfront as necessary (eventually making
      the HandleApiCall C++ builtin obsolete at some point).
      
      Bug: v8:8820, chromium:913553
      Change-Id: I10c0065016df4d0c24bac3d46945ea597b65ed02
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1469821
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59551}
      c142e0a2
  3. 17 Jan, 2019 1 commit
  4. 19 Dec, 2018 1 commit
  5. 04 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Refactor CallApiCallback calling convention · c6b0e12e
      Jakob Gruber authored
      This is the first (and major) step towards converting CallApiCallback
      and CallApiGetter stubs into builtins.
      
      The CallApiCallbackStub was parameterized with the number of arguments
      passed on the stack. This CL converts the compile-time parameter into
      an explicit runtime parameter, and removes all uses of the stub
      parameter.
      
      Drive-by: The implementation is now mostly consistent across platforms.
      Drive-by: Refactor the calling convention to free up two registers
      (kCallData and kHolder are now passed on the stack).
      
      Bug: v8:7777
      Change-Id: I212dccc2930de89c264a13755918c9fae7842f1f
      Reviewed-on: https://chromium-review.googlesource.com/c/1354887
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58005}
      c6b0e12e
  6. 30 Nov, 2018 1 commit
  7. 19 Nov, 2018 1 commit
  8. 31 Aug, 2018 1 commit
  9. 29 Aug, 2018 1 commit
  10. 28 Aug, 2018 1 commit
  11. 22 Aug, 2018 1 commit
  12. 22 Jun, 2018 1 commit
  13. 21 Jun, 2018 2 commits
  14. 18 Jun, 2018 1 commit
  15. 12 Jun, 2018 1 commit
  16. 07 Jun, 2018 1 commit
  17. 30 May, 2018 1 commit
  18. 25 May, 2018 1 commit
  19. 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
  20. 03 May, 2018 1 commit
  21. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored
      This is preparatory cleanup work for eventually tracking the functions
      (rather than concrete closures) in the CALL_IC, also for builtins like
      the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
      adds a new FeedbackCell type, which is used by JSFunctions consistently
      now to reference the feedback vector (or undefined if not the function
      is not compiled yet or is a native/asm.js function).
      
      This also changes the calling convention for FastNewClosure builtin and
      the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
      instead of the parent FeedbackVector and the slot index. In addition we
      eliminate the now unused %InterpreterNewClosure runtime function.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
      Reviewed-on: https://chromium-review.googlesource.com/928403
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  22. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored
      Moves generation of speculation poison to be based on the PC target vs the
      actual PC being executed. The speculation poison is generated in the prologue
      of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
      The result is stored in a known register, which can then be read using the
      SpeculationPoison machine node.
      
      Currently we need to ensure the SpeculationPoison node is scheduled right after
      the code prologue so that the poison register doesn't get clobbered. This is
      currently not verified, however it's only use is in RawMachineAssembler where
      it is manually scheduled early.
      
      The Ignition bytecode handlers are updated to use this speculation poison
      rather than one generated by comparing the target bytecode.
      
      BUG=chromium:798964
      
      Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
      Reviewed-on: https://chromium-review.googlesource.com/893160
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  23. 29 Jan, 2018 1 commit
  24. 21 Dec, 2017 1 commit
  25. 14 Dec, 2017 1 commit
  26. 16 Nov, 2017 1 commit
  27. 30 Oct, 2017 1 commit
  28. 25 Oct, 2017 1 commit
  29. 13 Oct, 2017 1 commit
  30. 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
  31. 05 Sep, 2017 1 commit
  32. 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
  33. 24 Aug, 2017 1 commit
  34. 15 Aug, 2017 1 commit
  35. 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
  36. 19 Jul, 2017 1 commit
  37. 14 Jul, 2017 1 commit
    • 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