1. 09 Jun, 2022 1 commit
    • Georgia Kouveli's avatar
      [arm64] Fix CFI issue with short builtin calls · fb235844
      Georgia Kouveli authored
      The allowlist used for `Deoptimizer::IsValidReturnAddress` depends on
      fixed embedded builtin addresses. Pass a pointer to the isolate to
      this method, so that it can discover the actual builtin code start
      (which may have been remapped) and calculate the offset from the start
      of the builtins' code in order to check if the return address is
      allowed.
      
      After this change, do not disable short builtin calls when CFI is
      enabled.
      
      There's an important TODO for this change:
      Since the builtin code pointer that's used to check whether a return
      address is allowed is now writable, we should use pointer authentication
      to protect it.
      
      Bug: v8:10026
      Change-Id: Iafd31d3ad7e10cb17faf33e76e78d3df36edeefd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667506Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/main@{#81049}
      fb235844
  2. 11 May, 2022 1 commit
  3. 28 Apr, 2022 1 commit
  4. 27 Apr, 2022 1 commit
  5. 26 Apr, 2022 1 commit
  6. 04 Apr, 2022 1 commit
  7. 29 Mar, 2022 1 commit
  8. 24 Mar, 2022 1 commit
  9. 21 Mar, 2022 1 commit
  10. 10 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Revert "[compiler] Don't remove OSR code cache if deoptimizing at out of loop" · 87f80671
      Jakob Gruber authored
      This reverts commit 190b5d95.
      
      Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9.
      
      Original change's description:
      > [compiler] Don't remove OSR code cache if deoptimizing at out of loop
      >
      > The main purpose of OSR compilation is fasten inner loop execution, the
      > OSR code cache is still correct for loop if optimizing at out of loop,
      > keep OSR code cache can reduce unnecessary slow bytecode execution with
      > feedback collection and avoid re-OSR compilation.
      > This CL can improve JetStream2 case navier-stokes by ~6%.
      >
      > Change-Id: I9518317fb922071b131cab5b56998a0fc198804a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Tao Pan <tao.pan@intel.com>
      > Cr-Commit-Position: refs/heads/main@{#79413}
      
      Bug: chromium:1304870
      Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79435}
      87f80671
  11. 09 Mar, 2022 1 commit
  12. 20 Jan, 2022 1 commit
  13. 11 Aug, 2021 1 commit
  14. 07 Jun, 2021 1 commit
  15. 08 Mar, 2021 1 commit
    • Clemens Backes's avatar
      [no-wasm] Remove deoptimizer support · 2cd2c488
      Clemens Backes authored
      This removes all includes of src/wasm from src/deoptimizer, by #if'ing
      out wasm-related parts. This will allow to later exclude the whole
      src/wasm directory from compilation.
      
      Drive-by: Inline DecodeWasmReturnKind and EncodeWasmReturnKind to avoid
      more #ifs.
      
      R=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: Ia49ed26fc217b3e80756a363dcd397d9060f6835
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739653Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73261}
      2cd2c488
  16. 26 Feb, 2021 1 commit
  17. 22 Feb, 2021 1 commit
  18. 15 Feb, 2021 2 commits
  19. 12 Feb, 2021 2 commits
  20. 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
  21. 25 Jan, 2021 1 commit
  22. 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
  23. 21 Jan, 2021 2 commits
  24. 20 Jan, 2021 2 commits
  25. 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
  26. 18 Jan, 2021 1 commit
  27. 17 Dec, 2020 3 commits
    • Nico Hartmann's avatar
      [TurboFan] Templatize GetBytecodeArray · d1226086
      Nico Hartmann authored
      This CL changes SharedFunctionInfo::GetBytecodeArray to a function
      template, which is specialized for Isolate and LocalIsolate arguments.
      This allows main thread only uses to avoid taking a lock.
      
      Bug: v8:7790, chromium:1154603
      Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71833}
      d1226086
    • 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
  28. 16 Dec, 2020 3 commits
  29. 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
  30. 20 Nov, 2020 1 commit
  31. 17 Nov, 2020 1 commit
  32. 10 Nov, 2020 1 commit