1. 11 Aug, 2022 1 commit
    • Darius M's avatar
      [compiler] Remove delayed string constants · de04959f
      Darius M authored
      StringConstantXXX were introduced when we switched to concurrent
      compilation, as a way to build strings in Turbofan in a background
      thread, without having to actually allocate them on the main heap
      from the background. See https://crrev.com/c/1221807.
      
      Now that we have local heaps, we can actually allocate strings from
      the background, making StringConstantXXX useless.
      
      Moreover, we would fold constant string concatenations into
      ConsString, which sounds a bit dubious for performance. Now, small
      constant string concatenations will be folded into SeqStrings, while
      larger ones will remain ConsString, just to avoid the quadratic
      worst-case.
      
      Change-Id: I0479d16aa5691c9d774187c4cc0d03ff4fe2b4f9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811291Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82381}
      de04959f
  2. 07 Jul, 2022 1 commit
  3. 13 May, 2022 1 commit
  4. 09 May, 2022 1 commit
  5. 29 Apr, 2022 1 commit
    • George Wort's avatar
      Make profile-guided optimization of builtins more configurable · 0e127bce
      George Wort authored
      Introduce get_hints.py and combine_hints.py in order to make
      the interpretation of basic block counts into hints more
      configurable and explicit, as well as allowing more accurate
      and consistent methods of combining multiple profiles.
      
      get_hints.py allows for the minimum count and threshold ratio
      values to be easily altered for different profiles, while
      combine_hints.py allows the hints produced from different
      benchmarks and threshold values to be easily and sensibly
      combined.
      
      Simply summing together basic block counts from different
      benchmarks could previously lead to a longer running benchmark
      overshadowing multiple shorter benchmarks with conflicting
      hints.
      
      Allowing alteration of the current threshold values gives a
      doubling of performance, while the new method of combining
      distinct profiles can double the performance improvement of the
      secondary benchmark while losing as little as 4% of the
      improvement gained in the primary benchmark.
      
      Design doc: https://docs.google.com/document/d/1OhwZnIZom47IX0lyceyt-S9i8AApDB0UqJdvQD6NuKQ/edit?usp=sharing
      
      Bug: v8:10470
      Change-Id: I1c09d1eabfdda5ed6794592e2c13ff8b461be361
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545181Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: George Wort <george.wort@arm.com>
      Cr-Commit-Position: refs/heads/main@{#80282}
      0e127bce
  6. 25 Apr, 2022 1 commit
  7. 06 Apr, 2022 1 commit
  8. 23 Mar, 2022 1 commit
    • Nico Hartmann's avatar
      Reland "[turbofan] Enable --verify-simplified-lowering in debug" · 87d73a3a
      Nico Hartmann authored
      This reverts commit aaedd8b7.
      
      Changes in the reland:
      The inital problem was caused by nodes that were removed during SL
      because they are no-ops but have an effect on typing (in the repro, this
      was e.g. PlainPrimitiveToNumber). The reland introdocues a new operator
      SLVerifierHint that is used exclusively in SL to provide hints to the
      verifier and that solves this problem. SLVerifierHint also replaces the
      previous use of TypeGuard to type constant nodes for the verifier.
      
      Bug: v8:12619, chromium:1302572
      Change-Id: I0957645c03d8b7c26cd6d630a1ecbd0a6a8223ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3512574Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79564}
      87d73a3a
  9. 22 Mar, 2022 1 commit
    • Darius M's avatar
      Reland^2 [compiler] Simplify "==0" branches in MachineOperatorReducer · 0719ace6
      Darius M authored
      This is a reland of 6b690a6b.
      
      The previous version of this CL was a bit too aggressive in the
      duplication of branch conditions. This caused an increase in
      register pressure in some cases, thus reducing performance.
      
      In fact, duplicating branch conditions that require an "== 0" to be
      added provides no benefits. We are thus now a bit less aggressive, and
      only duplicate comparisons.
      
      Original change's description:
      > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > This is a reland of 48b443f6.
      >
      > While fixing the initial CL, we stumbled upon a few bugs that
      > we had to fix:
      >
      >  - CommonOperatorReducer and SimplifiedOperatorReducer were applied
      >    before and after SimplifiedLowering, but always assumed that it
      >    was before SimplifiedLowering, and thus had the wrong semantics
      >    for branches in some cases. They now have an added parameter to
      >    know which semantics of branch they should use.
      >
      >  - The lowering of StaticAssert was wrong and could leave kHeapConstant
      >    in the assert (instead of machine Booleans).
      >
      > Original change's description:
      > > [compiler] Simplify "==0" branches in MachineOperatorReducer
      > >
      > > Bug: v8:12484
      > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#79379}
      >
      > Bug: v8:12484
      > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79528}
      
      Bug: v8:12484
      Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79560}
      0719ace6
  10. 21 Mar, 2022 2 commits
    • Darius Mercadier's avatar
      Revert "Reland [compiler] Simplify "==0" branches in MachineOperatorReducer" · b3a91634
      Darius Mercadier authored
      This reverts commit 6b690a6b.
      
      Reason for revert: causes a few regressions here https://chromeperf.appspot.com/group_report?rev=79528
      
      Original change's description:
      > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > This is a reland of 48b443f6.
      >
      > While fixing the initial CL, we stumbled upon a few bugs that
      > we had to fix:
      >
      >  - CommonOperatorReducer and SimplifiedOperatorReducer were applied
      >    before and after SimplifiedLowering, but always assumed that it
      >    was before SimplifiedLowering, and thus had the wrong semantics
      >    for branches in some cases. They now have an added parameter to
      >    know which semantics of branch they should use.
      >
      >  - The lowering of StaticAssert was wrong and could leave kHeapConstant
      >    in the assert (instead of machine Booleans).
      >
      > Original change's description:
      > > [compiler] Simplify "==0" branches in MachineOperatorReducer
      > >
      > > Bug: v8:12484
      > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#79379}
      >
      > Bug: v8:12484
      > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79528}
      
      Bug: v8:12484
      Change-Id: I457464d793e9c5af8448564aa3b46be863b96fbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540148
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79552}
      b3a91634
    • Jakob Gruber's avatar
      Remove dynamic map checks and custom deoptimization kinds · b2978927
      Jakob Gruber authored
      This CL removes:
      
      - Dynamic map checks aka minimorphic property loads (TF support,
        builtins).
      - "Bailout" deopts (= drop to the interpreter once, but don't
        throw out optimized code).
      - "EagerWithResume" deopts (= part of dynamic map check
        functionality, we call a builtin for the deopt check and deopt
        or resume based on the result).
      
      Fixed: v8:12552
      Change-Id: I492cf1667e0f54586690b2f72a65ea804224b840
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401585
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79544}
      b2978927
  11. 18 Mar, 2022 1 commit
    • Darius M's avatar
      Reland [compiler] Simplify "==0" branches in MachineOperatorReducer · 6b690a6b
      Darius M authored
      This is a reland of 48b443f6.
      
      While fixing the initial CL, we stumbled upon a few bugs that
      we had to fix:
      
       - CommonOperatorReducer and SimplifiedOperatorReducer were applied
         before and after SimplifiedLowering, but always assumed that it
         was before SimplifiedLowering, and thus had the wrong semantics
         for branches in some cases. They now have an added parameter to
         know which semantics of branch they should use.
      
       - The lowering of StaticAssert was wrong and could leave kHeapConstant
         in the assert (instead of machine Booleans).
      
      Original change's description:
      > [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > Bug: v8:12484
      > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79379}
      
      Bug: v8:12484
      Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79528}
      6b690a6b
  12. 12 Aug, 2021 1 commit
  13. 15 Jul, 2021 1 commit
  14. 05 Jul, 2021 1 commit
    • Georg Neis's avatar
      [compiler] Fix a (harmless) DCHECK failure · ce08dec0
      Georg Neis authored
      A frame state's outer frame state input can be kDeadValue. A DCHECK
      did not take that into account. In release builds there was no issue
      because we branch on the opcode anyways.
      
      While fixing this bug, I'm strengthening the FrameState class such that
      a FrameState node must have a kFrameState operator. I'm also
      - changing the result type of outer_frame_state() from FrameState to
        Node* since it may in fact not be a kFrameState;
      - removing has_outer_frame_state() because I find it unintuitive to
        have outer_frame_state() return non-NULL even when
        has_outer_frame_state() would return true.
      
      Bug: chromium:1224758
      Change-Id: I8ebed75c62e31f7eef71e2941fd18869d8a56af3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001356Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75553}
      ce08dec0
  15. 30 Jun, 2021 1 commit
  16. 21 May, 2021 1 commit
  17. 10 May, 2021 1 commit
  18. 04 Mar, 2021 1 commit
  19. 05 Feb, 2021 1 commit
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored
      This is a reland of 6ada6a90
      
      - Fixed a GC issue
        https://bugs.chromium.org/p/v8/issues/detail?id=11335:
        GC expected all arguments on the stack from code with
        CodeKind::TURBOFAN to be tagged objects. This is not the case now with
        inlined Wasm calls, and this information can be passed in
        SafepointEntry for each call site.
      
      - Disabled JS-to-Wasm inlining for calls inside try/catch.
      
      For more details, see updated doc:
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      
      Bug: v8:11092
      
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests).
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
      > generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  20. 27 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Add more StartNode helpers · e75d8dbc
      Jakob Gruber authored
      Start nodes for JS functions have the following Parameter node value
      outputs:
      
       closure, ...args_including_receiver, new_target, argc, context
      
      This CL adds helper functions for these. There's two interesting
      gotcha's:
      
      - Each Parameter node is associated with an index, starting at -1.
      Value output indices obviously start at 0, so there's an off-by-one
      between the value output of the Parameter node, and the Parameter
      node's associated index.
      - CSA/Torque graphs use different Start node layouts, yet these are
      not reflected in compiler logic. There's potential for confusion here.
      The two layouts should be unified or made explicit.
      
      Finally, tests create Start nodes with arbitrary layouts. This blocks
      removal of methods marked _MaybeNonStandardLayout.
      
      In an ideal world, the parameter index would equal the start node
      output index, and the layout of all Start nodes would be equal. Future
      work..
      
      Change-Id: I908909880817979062d459b7a80ed4fede40e2ec
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649035
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72352}
      e75d8dbc
  21. 22 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Revert "Reland "Faster JS-to-Wasm calls"" · 51ecfaec
      Paolo Severini authored
      This reverts commit 6ada6a90.
      
      Reason for revert: Revert for link issue:
      https://bugs.chromium.org/p/v8/issues/detail?id=11335
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests)
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      >
      >
      > Original change's description:
      > > Faster JS-to-Wasm calls
      > >
      > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      > >
      > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > > the basis of the signature of a Wasm function to call, and whose task
      > > is to:
      > > - set "thread_in_wasm_flag" to true
      > > - convert the arguments from tagged types into Wasm native types
      > > - calculate the address of the Wasm function to call and call it
      > > - convert back the result from Wasm native types into tagged types
      > > - reset "thread_in_wasm_flag" to false.
      > >
      > > This CL tries to improve the performance of JS-to-Wasm calls by
      > > inlining the code of the JS-to-Wasm wrappers in the call site.
      > >
      > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > > this kind of calls. A 'JSWasmCall' node is associated to
      > > WasmCallParameters, which contain information about the signature of
      > > the Wasm function to call.
      > >
      > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > > of the Wasm function, when the conversion is not necessary.
      > > The actual inlining of the graph generated for this wrapper happens in
      > > the simplified-lowering phase.
      > >
      > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > > lazy deoptimizations that can happen if the Wasm function callee calls
      > > back some JS code that invalidates the compiled JS caller function.
      > >
      > > Bug: v8:11092
      > > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > > Cr-Commit-Position: refs/heads/master@{#71824}
      >
      > Bug: v8:11092
      > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72147}
      
      Tbr: ahaas@chromium.org, jgruber@chromium.org
      Bug: v8:11092, v8:11335
      Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72253}
      51ecfaec
  22. 20 Jan, 2021 2 commits
  23. 19 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Reland "Faster JS-to-Wasm calls" · 6ada6a90
      Paolo Severini authored
      This is a reland of 860fcb1b
      
      - Disabled the tests for this feature in V8-lite mode (the original
      change broke V8-lite tests)
      - Also modified test console-profile-wasm.js that was brittle with this
      change because it assumed that there was always a JS-to-Wasm wrapper
      but this is not the case when the TurboFan compilation completes before
      the Liftoff-compiled code starts to run.
      
      More changes in Patchset 8:
      
      - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      into a new phase, wasm-inlining that reuses the JSInliner reducer.
      The doc
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      describes the new logic.
      
      - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      this should solve the problem we had inlining the calls in functions
      that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72147}
      6ada6a90
  24. 17 Dec, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "Faster JS-to-Wasm calls" · de50785e
      Nico Hartmann authored
      This reverts commit 860fcb1b.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
      
      Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:11092
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71825}
      de50785e
    • Paolo Severini's avatar
      Faster JS-to-Wasm calls · 860fcb1b
      Paolo Severini authored
      This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      
      Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      the basis of the signature of a Wasm function to call, and whose task
      is to:
      - set "thread_in_wasm_flag" to true
      - convert the arguments from tagged types into Wasm native types
      - calculate the address of the Wasm function to call and call it
      - convert back the result from Wasm native types into tagged types
      - reset "thread_in_wasm_flag" to false.
      
      This CL tries to improve the performance of JS-to-Wasm calls by
      inlining the code of the JS-to-Wasm wrappers in the call site.
      
      It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      this kind of calls. A 'JSWasmCall' node is associated to
      WasmCallParameters, which contain information about the signature of
      the Wasm function to call.
      
      WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      of the Wasm function, when the conversion is not necessary.
      The actual inlining of the graph generated for this wrapper happens in
      the simplified-lowering phase.
      
      A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      lazy deoptimizations that can happen if the Wasm function callee calls
      back some JS code that invalidates the compiled JS caller function.
      
      Bug: v8:11092
      Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis (ooo until January 5) <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71824}
      860fcb1b
  25. 16 Dec, 2020 1 commit
  26. 02 Dec, 2020 1 commit
  27. 01 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [Turboprop] Move deoptimizations for dynamic map checks into builtin. · b6643320
      Ross McIlroy authored
      In order to reduce the codegen size of dynamic map checks, add the
      ability to have an eager with resume deopt point, which can call
      a given builitin to perform a more detailed check than can be done
      in codegen, and then either deoptimizes itself (as if the calling
      code had performed an eager deopt) or resumes execution in the
      calling code after the check.
      
      In addition, support for adding extra arguments to a
      deoptimization continuation is added to enable us to pass the
      necessary arguments to the DynamicMapChecks builtin.
      
      Finally, a trampoline is added to the DynamicMapChecks which saves
      the registers that might be clobbered by that builtin, to avoid
      having to save them in the generated code. This trampoline also
      performs the deoptimization based on the result of the
      DynamicMapChecks builtin.
      
      In order to ensure both the trampoline and DynamicMapChecks
      builtin have the same call interface, and to limit the number
      of registers that need saving in the trampoline, the
      DynamicMapChecks builtin is moved to be a CSA builtin with a
      custom CallInterfaceDescriptor, that calls an exported Torque
      macro that implements the actual functionality.
      
      All told, this changes the codegen for a monomorphic dynamic
      map check from:
          movl rbx,<expected_map>
          cmpl [<object>-0x1],rbx
          jnz <deferred_call>
         resume_point:
          ...
         deferred_call:
          <spill registers>
          movl rax,<slot>
          movq rbx,<object>
          movq rcx,<handler>
          movq r10,<DynamicMapChecks>
          call r10
          cmpq rax,0x0
          jz <restore_regs>
          cmpq rax,0x1
          jz <deopt_point_1>
          cmpq rax,0x2
          jz <deopt_point_2>
          int3l
         restore_regs:
          <restore_regs>
          jmp <resume_point>
          ...
         deopt_point_1:
          call Deoptimization_Eager
         deopt_point_2:
          call Deoptimization_Bailout
      
      To: movl rax,<slot>
          movl rcx,<expected_map>
          movq rdx,<handler>
          cmpl [<object>-0x1],rcx
          jnz <deopt_point>
         resume_point:
          ...
         deopt_point:
          call DynamicMapChecksTrampoline
          jmp <resume_point>
      
      BUG=v8:10582
      
      Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71545}
      b6643320
  28. 06 Nov, 2020 1 commit
  29. 03 Sep, 2020 1 commit
  30. 02 Sep, 2020 2 commits
  31. 29 Jul, 2020 1 commit
  32. 27 Jul, 2020 1 commit
  33. 17 Mar, 2020 1 commit
  34. 05 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [compiler] Optimize AddInputsToFrameStateDescriptor · 500d73b9
      Dan Elphick authored
      Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
      taking advantage of SparseInputMask data structure to more quickly
      handle empty inputs and insert all the OptimizedOut entries in one go.
      The number of empty inputs is now determined using CountTrailingZeros
      rather than iterating over them one at a time.
      
      Gives a 9% improvement to SelectInstructions runtime call stat for
      Octane in turboprop.
      
      Bug: v8:10051
      Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66591}
      500d73b9
  35. 04 Mar, 2020 1 commit
  36. 02 Mar, 2020 1 commit