return ReduceIfReachableAssertNotNull(This is a general observation with any operation that I add support for in the Wasm-in-JS body inlining (and thus the JS pipeline): I always need to add these optional FrameStates. Is there maybe a smarter way to reuse more code with smaller diffs from the Turboshaft graph builder? Should I add a global `wasm_inlining_frame_state` to the `PipelineData` (or somewhere else) instead of threading it through the operations?
struct AssertNotNullOp : OperationT<AssertNotNullOp> {See question above. Much of this CL is simply threading the `frame_state` through, maybe we should just get it for `TrapIf` (when lowering) from some global state...
V<Word32> length = __ ArrayLength(Drive-by `V<>`ifycation.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
return ReduceIfReachableAssertNotNull(This is a general observation with any operation that I add support for in the Wasm-in-JS body inlining (and thus the JS pipeline): I always need to add these optional FrameStates. Is there maybe a smarter way to reuse more code with smaller diffs from the Turboshaft graph builder? Should I add a global `wasm_inlining_frame_state` to the `PipelineData` (or somewhere else) instead of threading it through the operations?
Uh, I think I found a nice solution, see https://crrev.com/c/7726388: How about implementing `REDUCE(TrapIf)` in the WasmInJsInliningReducer, which passes in a "currently active FrameState", which it gets from the surrounding JS->Wasm call. Then all the intermediate ops don't need to know about it and I don't need to touch the Turboshaft Assembler interface, *Ops, nor `WasmLoweringReducer`.
Matthias, Darius, WDYT about that?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |