[Wasm RyuJIT] Implement Wasm DFS and Loop Finding

[AndyAyersMS]

Loops for Wasm control flow codegen don't involve EH or runtime mediated
control flow transfers.

Implement a custom block successor enumerator for Wasm, and adjust fgRunDFS
to allow using this and also to generalize how the DFS is initiated. Use
this to build a "Wasm" DFS. In that DFS handle both the main method and
all funclets (by specifying funclet entries as additional DFS starting points).

Update the loop finding code to make suitable changes when it is driven from
a "Wasm" DFS instead of the typical all successor / all predecessor DFS.

Remove the restriction in the Wasm control flow codegen that only handles
the main method; now it works for the main method and all funclets.

Contributes to #121178.

Dependent on #121417.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This PR implements a custom DFS (depth-first search) and loop finding mechanism specifically for WebAssembly control flow code generation. The implementation introduces a Wasm-specific successor enumerator that excludes exceptional control flow and runtime-mediated transfers, allowing the Wasm control flow codegen to handle both the main method and all funclets.

Key changes include:

• Introduction of WasmSuccessorEnumerator class that enumerates successors following Wasm control flow rules
• Generalization of fgRunDfs to accept custom successor enumerators and multiple entry blocks
• Addition of fgWasmDfs() method that builds a DFS tree treating funclets as separate disjoint regions
• Updates to loop finding logic to handle Wasm-specific control flow patterns (callfinally pairs, funclet returns)

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/jit/jitconfigvalues.h	Changes default value of JitWasmControlFlow from 0 to 1
src/coreclr/jit/flowgraph.cpp	Refactors fgComputeDfs and FindNaturalLoopBlocks to support multiple entry blocks and Wasm-specific control flow
src/coreclr/jit/fgwasm.h	Adds new header defining WasmSuccessorEnumerator and VisitWasmSuccs for Wasm control flow
src/coreclr/jit/fgwasm.cpp	Implements WasmSuccessorEnumerator, fgWasmDfs, and updates fgWasmControlFlow to handle funclets
src/coreclr/jit/fgdiagnostic.cpp	Updates debug flow graph checking to use new fgRunDfs signature with entry blocks
src/coreclr/jit/compiler.hpp	Generalizes fgRunDfs template to accept SuccessorEnumerator parameter and entry blocks vector
src/coreclr/jit/compiler.h	Adds fgWasmDfs declaration, IsForWasm methods, and updates fgRunDfs signature
src/coreclr/jit/CMakeLists.txt	Adds fgwasm.h to JIT_WASM_HEADERS list

[AndyAyersMS]

@dotnet/jit-contrib PTAL

I will probably capture those global functions in a helper class in the next round of work.

@jakobbotsch this is the "smaller" generalization of DFS to accommodate some special needs for Wasm:

• different successor enumeration
• different set of entry blocks.

I held off folding in "only walk a subgraph" and "walk the reverse graph" from this. So there is a different wasm-specific DFS also in the world (currently just does the subgraph bit).

I have to make some assumptions at this point about how EH control flow is going to work. If we end up implementing some of the EH via Wasm EH we'll need to make corresponding adjustments here.

For example, non-funclet blocks that are only reachable via EH don't get properly handled here, as there is (in this current simple "model") no wasm-visible way for control to reach them. Methods with such blocks are fairly rare.

[AndyAyersMS]

@dotnet/jit-contrib ping

[AndyAyersMS]

The next bit of work after this adds the ability to transform SCCs. Preview here: #121728

[jakobbotsch]

I think it looks ok. I am fine with merging this as is.

One thing that would be nice is if details about WASM didn't leak into FlowGraphDfsTree. Maybe an abstraction could be a GraphDetails class that gives pred/successor/entry blocks visitors, and we would have FlowGraphDetails and WasmFlowGraphDetails implementations of that. The current FlowGraphDfsTree would be defined as some using FlowGraphDfsTree = DfsTree<FlowGraphDetails> and similar for FlowGraphNaturalLoops. Then the WASM stuff could have its own definitions of DFS tree and loops created over its own structure of the flow graph.

[AndyAyersMS]

I think it looks ok. I am fine with merging this as is.

One thing that would be nice is if details about WASM didn't leak into FlowGraphDfsTree. Maybe an abstraction could be a GraphDetails class that gives pred/successor/entry blocks visitors, and we would have FlowGraphDetails and WasmFlowGraphDetails implementations of that. The current FlowGraphDfsTree would be defined as some using FlowGraphDfsTree = DfsTree<FlowGraphDetails> and similar for FlowGraphNaturalLoops. Then the WASM stuff could have its own definitions of DFS tree and loops created over its own structure of the flow graph.

It also leaks into the Loop classification, since that needs to walk the reverse flow.

Let me look into this after I get the next bit of work merged.

[AndyAyersMS]

/ba-g scheduled macos-13 brownout.