Make ISLE dataflow optimization control-flow aware (BrIf/BrTable)

[avrabe]

Context

PR #53 eliminated the has_unsupported_isle_instructions skip block — all standard WASM instructions are now wired into the ISLE pipeline. However, functions containing BrIf or BrTable are still skipped by has_dataflow_unsafe_control_flow for the two term-rewriting passes (optimize_term_rewriting and optimize_advanced_instructions).

Problem

The ISLE dataflow optimization (simplify_with_env) can incorrectly move side effects outside of control flow blocks. For example, a LocalSet after a BrIf may be moved to execute unconditionally — a semantic violation.

This means functions with conditional branches don't get term-rewriting optimizations (constant propagation through locals, redundant load elimination, etc.), even though they now get all other passes (DCE, branch simplification, code folding, etc.).

Solution

Make the dataflow analysis control-flow aware:

1. Track which values are defined inside conditional blocks
2. Don't propagate LocalSet values across branch boundaries
3. Consider using dominator tree analysis to determine safe propagation points
4. Or: split the function into basic blocks and optimize each independently

Files

• loom-core/src/lib.rs: has_dataflow_unsafe_control_flow (line ~6654), optimize_term_rewriting (line ~6689), optimize_advanced_instructions (line ~10700)

Impact

This is the last major optimization coverage gap. Removing this restriction would give every function full optimization, not just functions without conditional branches.

[avrabe]

Investigation findings (2026-03-27)

Attempted to make ISLE dataflow optimization control-flow aware by adding env clearing at BrIf/BrTable/Call/CallIndirect in simplify_with_env. This clears all tracked locals and memory at each control flow boundary.

Result: Not sufficient for loop back-edges.

Z3 found a counterexample in test_licm_constant_hoist when the has_dataflow_unsafe_control_flow check was removed. The problem:

1. instructions_to_terms flattens the loop body into a linear term stream
2. simplify_with_env processes terms sequentially, tracking local.set values
3. When br_if at the end of the loop branches back, the env has stale values from the current iteration
4. On the next iteration (in the real program), locals may have different values
5. But in the term stream, there IS no "next iteration" — it's a single pass

The env clearing at BrIf helps for non-loop cases (if/else branches) but doesn't solve the fundamental problem: the term stream doesn't model loop back-edges.

Required approach for #56

The proper fix needs one of:

• Basic block splitting: Split instruction stream at branch points, optimize each BB independently, then stitch back
• Loop-aware env: Save env at loop entry, restore at br_if that targets the loop, verify convergence
• SSA conversion: Convert to SSA form where each local assignment gets a unique name

PR #64 adds the env clearing as defense-in-depth for future work.