JIT: Compact newly recognized loops #97149
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsLarge diffs expected. Sadly that's just churn until we get a new block layout in the backend, but I do not see an easy way to avoid it if we want to be able to remove old loop finding.
|
|
cc @dotnet/jit-contrib PTAL @BruceForstall Diffs. A significant amount of churn, that I sadly don't have a good idea on how to avoid. |
| // If this is a CALLFINALLYRET that is not in the loop, but the | ||
| // CALLFINALLY was, then we have to leave it in place. For compaction | ||
| // purposes this doesn't really make any difference, since no codegen | ||
| // is associated with the CALLFINALLYRET anyway. | ||
| if (cur->isBBCallFinallyPairTail()) | ||
| { | ||
| cur = cur->Next(); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
This is an interesting case that can occur since we do not return any EH succeessors for CALLFINALLYRET; if the CALLFINALLY/CALLFINALLYRET is inside a try whose handler loops back around, then the CALLFINALLY may be part of the loop while the CALLFINALLYRET isn't. Here's an example case; red edges are EH successor edges. The CALLFINALLY is BB19 and the CALLFINALLYRET is BB20.
Large diffs expected. Sadly that's just churn until we get a new block layout in the backend, but I do not see an easy way to avoid it if we want to be able to remove old loop finding.