JIT: boost loop inversion cost limit for some loops#129472
Conversation
Recognize loops where the IV increment is in the backedge source block and also might profit from loop cloning. Increase the cost limit for such cases. Fixes dotnet#119693. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Pull request overview
This PR adjusts CoreCLR JIT loop inversion profitability heuristics to more often allow while/for loop inversion in cases that are likely to benefit from subsequent loop cloning (notably when the IV increment is in a backedge source block rather than the condition block).
Changes:
- Tracks whether a loop “might benefit from cloning” outside the size-limit gate so it can be reused by later inversion-cost heuristics.
- Adds detection for “split IV test + increment” patterns (increment in a backedge source block) and boosts the allowed duplication cost to make inversion more likely.
- Extends verbose DEBUG diagnostics to report the new heuristic signal.
| if ((optInvertInfo.sharedStaticHelperCount > 0) || (optInvertInfo.arrayLengthCount > 0) || | ||
| hasSplitIVTestAndIncrement) | ||
| { | ||
| // Calculate a new maximum cost. We might be able to early exit. | ||
|
|
|
Still working on this so no rush to review. |
Actually no... was looking at what it would take to get rid of the in-loop bounds check, but it is out of reach (the array is a loop invariant but we'd need it to be CSEd first). PTAL @jakobbotsch Diff for the issue's case is:
|

Recognize loops where the IV increment is in the backedge source block and also might profit from loop cloning. Increase the cost limit for such cases to enable inversion (which in turn enables cloning and other opts).
Fixes #119693.