relooper: Avoid recomputing strict_reachable_from in simple case#1827
relooper: Avoid recomputing strict_reachable_from in simple case#1827randomPoison wants to merge 2 commits into
Conversation
fw-immunant
left a comment
fw-immunant
left a comment
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?
| let has_back_edge = local_successors | ||
| .values() | ||
| .any(|successors| successors.contains(entry)); | ||
|
|
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?
There was a problem hiding this comment.
We don't need the full transitive reachability here, we just need to know if there's a back edge to our entry in our current set of blocks since that determines if we can create a Simple or if we need to make a Loop. We can determine that from local successors alone, i.e. if one of our current blocks has the entry as its immediate successor. I used the transitive reachability info originally because it seemed convenient and we needed to compute transitive reachability anyway, but I was not taking performance into account >__>
Is this connected to the comment on
strict_reachable_fromthat 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?
So that comment is calling out why we can't just compute reachability for the entire graph up front and then reuse that info for the entire relooping. The problem with that is that when we process a loop we strip back edges, which then changes reachability info (which is important for correctly processing the sequence of blocks within the loop body). The new comment is calling out that the reachability info only meaningfully changes when we strip back edges, so in theory we only need to recompute reachability after processing a loop body. Avoiding that recomputation might help performance when dealing with very large CFGs, but would also require some more careful thought about if stale reachability would cause problems later in relooper, so doesn't seem important to do right now.
Co-authored-by: Frances Wingerter <91758128+fw-immunant@users.noreply.github.com>
2 participants
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.