Cranelift: Rewrite conditional branches with constant conditions into unconditional jumps#13267
Merged
fitzgen merged 5 commits intoMay 12, 2026
Conversation
cfallin
approved these changes
May 4, 2026
Member
cfallin
left a comment
cfallin
left a comment
There was a problem hiding this comment.
Nice -- I'm happy to see how this is actually pretty straightforward given all of the primitives that we have! The RPO traversal change makes sense; just a comment below on how we describe/justify it. And a small request for testing. Otherwise LGTM!
cfallin
requested changes
May 4, 2026
github-actions
Bot
added
cranelift
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
cfallin
approved these changes
May 7, 2026
Member
cfallin
left a comment
cfallin
left a comment
There was a problem hiding this comment.
Looks great -- thanks for the very detailed proof!
Member
|
(Merge conflict to resolve before this can merge) |
… unconditional jumps This requires two tweaks to the egraph pass's machinery: 1. We maintain a set of reachable blocks. This is initialized to the entry block. After optimizing a block's intructions, we look at the terminator and mark any other block it branches to as reachable. When visiting blocks to optimize their instructions, we skip unreachable blocks and remove them and their instructions from the function's layout. 2. We always visit blocks in reverse-post order, rather than dominator-tree order (which is related but slightly weaker). This ensures that we always visit predecessors before successors, and therefore that if a block is not marked reachable, then it really is unreachable and is safe to remove. See code comments for the details of when dominator-tree order breaks down.
Lowering expects them
And include a proof of why the new traversal is correct.
fitzgen
force-pushed
the
cranelift-simplify-block-terminators
branch
from
f9f5a48 to
79c2c61
Compare
We were re-processing an instruction we already processed, which led to a failing assertion due to a missing entry in `value_to_opt_value` for certain kinds of union nodes which can only be seen by our side-effectful instruction re-processing. We could ensure that we have `value_to_opt_value` entries for these values, but we don't have any `simplify_skeleton` rules that benefit from re-processing, so what is the point of introducing a bunch of new stores during compilation? Let's just stop re-processing side-effectful instructions instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This requires two tweaks to the egraph pass's machinery:
We maintain a set of reachable blocks. This is initialized to the entry block. After optimizing a block's intructions, we look at the terminator and mark any other block it branches to as reachable. When visiting blocks to optimize their instructions, we skip unreachable blocks and remove them and their instructions from the function's layout.
We always visit blocks in reverse-post order, rather than dominator-tree order (which is related but slightly weaker). This ensures that we always visit predecessors before successors, and therefore that if a block is not marked reachable, then it really is unreachable and is safe to remove. See code comments for the details of when dominator-tree order breaks down.