relooper: Avoid recomputing strict_reachable_from in simple case#1827
Open
randomPoison wants to merge 1 commit into
Open
relooper: Avoid recomputing strict_reachable_from in simple case#1827randomPoison wants to merge 1 commit into
randomPoison wants to merge 1 commit into
Conversation
fw-immunant
reviewed
May 28, 2026
fw-immunant
left a comment
fw-immunant
left a comment
Contributor
There was a problem hiding this comment.
One question and one comment suggestion inline.
Also, is it possible/feasible to add a test case here?
Comment on lines
+254
to
+257
| let has_back_edge = local_successors | ||
| .values() | ||
| .any(|successors| successors.contains(entry)); | ||
|
|
Contributor
There was a problem hiding this comment.
has_back_edge here seems to match the original condition here--"if the entry is in the transitive closure of any of its successors, there is a back edge". But the new condition doesn't search transitively. What justifies only looking at immediate successors? Is this connected to the comment on strict_reachable_from that says we only consider the local set of blocks? How does this relate to the comment that says "we don't want to consider back edges"--are we possibly "inside a loop" here?
Comment on lines
+245
to
+247
| // TODO: If possible we should avoid recomputing this every time. I think the | ||
| // reachability information only meaningfully changes when we strip a back edge, | ||
| // so in theory we should only need to recompute this after processing a loop. |
Contributor
There was a problem hiding this comment.
Suggested change
| // TODO: If possible we should avoid recomputing this every time. I think the | |
| // reachability information only meaningfully changes when we strip a back edge, | |
| // so in theory we should only need to recompute this after processing a loop. | |
| // TODO: If possible we should avoid recomputing this every time `relooper` recurses. I think the | |
| // reachability information only meaningfully changes when we strip a back edge, | |
| // so in theory we should only need to recompute this after processing a loop. |
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.
Fixes #1821 by avoiding computing
strict_reachable_fromin the case of linear control flow. The performance issue there was that we were recomputingstrict_reachable_fromin every call torelooper, which means we recompute it after processing each block in the CFG. For very long CFGs like the one in #1821 that results in a lot of redundant work, causing translation to take a very long time.The fix for the specific case in #1821 is simple, but I suspect there are other edge cases that could cause similar quadratic behavior. I think we could be a bit smarter about when we recompute reachability info, since I think reachability only meaningfully changes when we strip back edges while processing a loop. I don't have time to experiment with that now, though, so I've added a TODO comment in there as a note to look into that in the future.