• 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
js-inlining.h 3.03 KB