Skip to content

Handle irreducible control flow in branch simplification#13385

Open
fitzgen wants to merge 1 commit into
bytecodealliance:mainfrom
fitzgen:issue-13365-branch-optimization-bug
Open

Handle irreducible control flow in branch simplification#13385
fitzgen wants to merge 1 commit into
bytecodealliance:mainfrom
fitzgen:issue-13365-branch-optimization-bug

Conversation

@fitzgen
Copy link
Copy Markdown
Member

@fitzgen fitzgen commented May 15, 2026

We previously removed a block from the CFG if it was not marked as reachable by the time the egraph pass visited it. The pass's traversal is both (1) a depth-first pre-order dominator traversal, and (2) a reverse post-order CFG traversal. This traversal visits all of a block's non-back edge predecessors before visiting the block itself. For reducible control flow, this is all that is necessary because we've already visited every back edge's target block already.

However, for irreducible control flow, blocks can be reachable only through back edges, and so the traversal's property alone was not sufficient. (The EgraphBlockIter's proof is still correct, at least to the best of my knowledge since we haven't mechanically proven it, but the implicit assumption that its proven property is sufficient for our reachability-based block removal is incorrect in the face of irreducible control flow.)

This commit's fix is to only remove blocks when they haven't been marked reachable and all of its predecessors have been visited (this latter bit being the thing that irreducible control flow broke). To implement this, we pass in the already-computed ControlFlowGraph from the Context into the EgraphPass so that we can easily iterate of a block's predecessors.

Fixes #13365

We previously removed a block from the CFG if it was not marked as reachable by
the time the egraph pass visited it. The pass's traversal is both (1) a
depth-first pre-order dominator traversal, and (2) a reverse post-order CFG
traversal. This traversal visits all of a block's non-back edge predecessors
before visiting the block itself. For reducible control flow, this is all that
is necessary because we've already visited every back edge's target block
already.

However, for irreducible control flow, blocks can be reachable *only* through
back edges, and so the traversal's property alone was not sufficient. (The
`EgraphBlockIter`'s proof is still correct, at least to the best of my knowledge
since we haven't mechanically proven it, but the implicit assumption that its
proven property is sufficient for our reachability-based block removal is
incorrect in the face of irreducible control flow.)

This commit's fix is to only remove blocks when they haven't been marked
reachable *and* all of its predecessors have been visited (this latter bit being
the thing that irreducible control flow broke). To implement this, we pass in
the already-computed `ControlFlowGraph` from the `Context` into the `EgraphPass`
so that we can easily iterate of a block's predecessors.

Fixes bytecodealliance#13365
@fitzgen fitzgen requested a review from cfallin May 15, 2026 12:45
@fitzgen fitzgen requested a review from a team as a code owner May 15, 2026 12:45
@fitzgen fitzgen removed the request for review from a team May 15, 2026 12:45
@github-actions github-actions Bot added the cranelift Issues related to the Cranelift code generator label May 15, 2026
@cfallin
Copy link
Copy Markdown
Member

cfallin commented May 15, 2026

I guess I come back to the point I made here: we now have a pretty complex approach (with a very intricate proof, to your credit!) that only mostly satisfies the requirements, but (with this patch) will sometimes not fully DCE dead branches. On the other hand, if we had a separate DFS-over-blocks to find reachable blocks, we would (with a pretty simple implementation we could be pretty certain about) have correct reachable-code computation in all cases, without having to conservatively over-approximate and leave some dead code in place. Perhaps we should consider that approach again? Can we at least measure its compile-time impact?

@fitzgen
Copy link
Copy Markdown
Member Author

fitzgen commented May 15, 2026

Yeah, I thought about that too. I'll investigate a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cranelift Issues related to the Cranelift code generator

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid CLIF generated from conditional branch rewrite optimizations

2 participants