3563dd1

[JSC] Fast JS-to-Wasm call from FTL
https://bugs.webkit.org/show_bug.cgi?id=250545
rdar://104214223

Reviewed by Keith Miller.

This patch supports direct Wasm call from FTL. FTL can know type speculations.
We check this in DFG strength reduction phase, and generate appropriate stack and register assignment for Wasm call.
This is further more efficient than Wasm IC since,

1. Based on type speculation, we can skip many type checks for arguments.
2. Because FTL can control registers and stacks, we can appropriately configure values in the right argument registers
   and stack location in FTL side and directly call Wasm function from FTL. By using patchpoint, B3 can assign right registers / stack
   location for them.
3. This removes Wasm IC trampoline between JS and Wasm function. Wasm function is now directly called from JS.

To make this work, we require 259139@main. That change allows us to remove a hack in unwinding for wasm (wasm function call can modify global state (vm.wasmContext.instance),
and unwinding needed to restore them appropriately. The above patch removed this necessity).
As a result, we can directly call wasm function from FTL without doing a hack in unwinding. And we can also remove save / restore of vm.wasmContext.instance.

We also need to encourage CallWasm in DFG ByteCodeParser. CallWasm needs constant-folded callee currently, but it needs to be materialized well from DFG ByteCodeParser by inserting
appropriate checks from CallVariant.

Note that we are reporting wasm pinned registers' clobbering from FTL patchpoint. This teaches FTL to save and resume these callee-save registers as FTL's callee-save registers.
Thus, OSR exit / exception unwinding just works well: FTL cares these registers and correctly restore them when OSR exit happens. This is also the reason why we cannot apply
this optimization to TailCall right now: wasm function clobbers callee-save registers and tail-call needs an adaptor to restore them correctly when returning to the caller's caller.
In the future, we should align wasm pinned registers with JS JIT default callee-save registers so that we can easily restore then when OSR exit happens from DFG too. This is necessary
if we would like to introduce this direct call from DFG side.

This improves JetStream2/richards-wasm Runtime from 13.021 to 16.129, 23% improvement.

* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* Source/JavaScriptCore/dfg/DFGMayExit.cpp:
* Source/JavaScriptCore/dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToCallWasm):
* Source/JavaScriptCore/dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasCellOperand):
* Source/JavaScriptCore/dfg/DFGNodeType.h:
* Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp:
* Source/JavaScriptCore/dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileCallWasm):
(JSC::DFG::SpeculativeJIT::compile):
* Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* Source/JavaScriptCore/ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):

Canonical link: https://commits.webkit.org/259250@main

60d8b82