-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[Wasm RyuJIT] Wasm control flow basics #121417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Determine how to emit Wasm control flow from the JIT's control flow graph. Relies on loop-aware RPO to determine the block order. Currently only handles the main method. Assumes irreducible loops have been fixed upstream (which is not yet guaranteed; bails out if not so). Doesn't actually do any emission, just prints a textual description in the JIT dump (along with a dot markup version). Uses only LOOP and BLOCK. Tries to limit the extent of BLOCK. Run for now as an optional phase even if not targeting Wasm, to do some stress testing. Contributes to dotnet#121178
|
FYI @dotnet/jit-contrib @SingleAccretion a first cut at wasm control flow. Eventually the text emission will end up being part of emitwasm (and in binary, with text disasm) and not part of this phase. Left: sample control flow graph. Black are Wasm blocks, red are Wasm loops. Right: sample Wasm instruction stream (block contents not shown, just |
|
The FALLTHROUGH-inv above is a reminder we need to invert the branch condition (not yet done). |
|
Think this is ready for review. There could still be bugs in the control flow, but hard to be sure until we can actually generate code. Errors seem to be all known or timeouts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds a new experimental Wasm control flow simulation phase to the JIT compiler. The phase analyzes the control flow graph and simulates how Wasm BLOCK/END and LOOP/END control structures would be emitted for the method being compiled.
- Introduces a new
fgWasmControlFlowphase that transforms the control flow graph into Wasm-style nested control structures - Adds a
JitWasmControlFlowconfiguration option to enable/disable this experimental feature (DEBUG builds only) - Implements an interval-based algorithm to properly nest blocks and loops according to Wasm requirements
Reviewed Changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/jit/jitconfigvalues.h | Adds the JitWasmControlFlow configuration integer to control the new phase |
| src/coreclr/jit/fgwasm.cpp | New file implementing the Wasm control flow analysis and simulation algorithm |
| src/coreclr/jit/compphases.h | Registers the PHASE_WASM_CONTROL_FLOW phase |
| src/coreclr/jit/compmemkind.h | Adds CMK_Wasm memory kind for allocations |
| src/coreclr/jit/compiler.h | Declares the fgWasmControlFlow method |
| src/coreclr/jit/compiler.cpp | Invokes the new phase conditionally in DEBUG builds after loop alignment |
| src/coreclr/jit/CMakeLists.txt | Adds fgwasm.cpp to the build sources |
Co-authored-by: Copilot <[email protected]>
|
@dotnet/jit-contrib PTAL |
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
|
@dotnet/jit-contrib ping |
|
LGTM but I'll leave the green check to someone who knows the JIT better |
|
I should do a run where I enable this in release just to see the TP impact... will do that locally and report back. |
Enabling this in release, it has about a 0.5-0.9% TP hit. Worst-case was benchmaks.pgo at 0.92. Restricting the analysis to running just on methods with optimization (as it will be doing mostly, R2R code is optimized) drops this to 0.55%. Breaking it down by stages so no clear bottleneck. |
|
The new phase is now disabled. I will create a wasm test pipeline where we can enable this. |
|
/ba-g one test failed with Half-way through waiting for remote process. Memory load: 18 Unrelated |

Determine how to emit Wasm control flow from the JIT's control flow graph.
Relies on loop-aware RPO to determine the block order. Currently only handles the main method. Assumes irreducible loops have been fixed upstream (which is not yet guaranteed; bails out if not so).
Doesn't actually do any emission, just prints a textual description in the JIT dump (along with a dot markup version).
Uses only LOOP and BLOCK. Tries to limit the extent of BLOCK.
Run for now as an optional phase even if not targeting Wasm, to do some stress testing.
Contributes to #121178