[wasm][turboshaft] Support ref.cast in Wasm-in-JS body inlining [v8/v8 : main]
Daniel Lehmann (Gerrit)
Daniel Lehmann added 7 comments![]( "Open in Gerrit")
Not quite one-shot in the end, but most edits went through some agent back and forth and certainly much quicker than I would've been able to...
bool has_rtt;`WasmTypeCastOp` now has two optional arguments. The FrameState, depending on whether it's in the JS pipeline or the regular Wasm pipeline, and the RTT, depending on whether it's casting to an abstract heap type or not. Before, it used the input count to derive whether the RTT is present or not, but with two optional arguments, that's ambiguous now.
to->op = from.op;Sometimes the FunctionBodyDecoder already optimizes casts "statically" to this.
if (v8_flags.experimental_wasm_assume_ref_cast_succeeds) {Same here, basically a copy from the regular Wasm pipeline.
if (target.is_shared() == SharedFlag::kYes) {Except for the bailout on shared types, and the added `frame_state_`, this is identical to the implementation in `turboshaft-graph-interface.cc`.
V<FixedArray> managed_object_maps() {This helper is a bit useless, but this way the connection to the `turboshaft-graph-interface.cc` is more apparent.
const wasm::WasmModule* module() {Since the module is set during the `WasmInJSInliningReducer`, we cannot initialize the field too early. I don't think this is performance critical enough to warrant some kind of lazy initialized-on-first-access cache, but WDYT?
Related details
- Matthias Liedtke
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |