JIT: invert oversize loops with their own bounds checks

[AndyAyersMS]

Relax optTryInvertWhileLoop's heuristic for loops with bounds checks in their own blocks (not just in nested loop blocks). Remove "too big to clone" and "1.25x liberal" limits.

Bail out when any nested loop has its own bounds checks: those nested loops will be inverted and cloned on their own merits, and inverting (then cloning) this larger outer loop on top of that just duplicates the entire nested body and disrupts downstream LICM/CSE on sibling code (e.g. Benchstone.BenchF.InvMt).

Partially mitigates some cases in issue #116486.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the JIT’s loop inversion heuristic in optTryInvertWhileLoop to be more permissive for larger loops when bounds checks suggest loop cloning could be profitable, and to avoid using prior “too big / 1.25x” size caps.

Changes:

• Reworks inversion size gating to track bounds checks separately for the current loop vs. nested loops.
• Removes the “too big to clone” and “1.25x liberal” rejection logic, deferring more size decisions to later duplication/cloning budgets.
• Adds a specific bailout for the “bounds checks only exist in nested loops” case.

[AndyAyersMS]

Still messing with inversion heuristics. Probably needs more tweaking.

[AndyAyersMS]

@jakobbotsch PTAL
fyi @dotnet/jit-contrib

Allow a bit more inversion, partially decouple from cloning.

[AndyAyersMS]

@EgorBot -intel -arm --filter "Benchstone.BenchF.Romber"

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[AndyAyersMS]

diffs

More code size than I was expecting... I wish there was some way to estimate where we are net-net versus .NET 10, since we also have had a number of large reductions.

Tempted to say we should take this as-is.

I can also keep looking for indicators that inversion is not going to be beneficial.

[BoyBaykiller]

I wonder if with this we invert the loop in #121533 (comment) again.

[AndyAyersMS]

Note

Generated with AI assistance.

@BoyBaykiller yes — confirmed. With this PR your RadixSort repro's outer loop gets inverted again and strength reduction kicks back in.

JIT dump side-by-side with current main (8216cbe) vs this PR:

BASE (current main): DIFF (this PR):
L00 exceeds inversion size limit of 100 L00 exceeds inversion size limit of 100
L00 might benefit from cloning, L00 might benefit from cloning. Continuing.
but is too large to invert.
Could not extract an IV
Could not extract an IV
LoopsMadeDownwardsCounted: 0 LoopsMadeDownwardsCounted: 1

The "might benefit from cloning, but is too large to invert" message from issue #121533 comes from the exact liberalInvertSizeLimit gate this PR removes.

[AndyAyersMS]

@EgorBot -windows_azure_emeraldrapids -commits 0d1a20f,41be5e229b3~1 --filter "*Perf_Version.TryFormat4"

[AndyAyersMS]

@EgorBot -intel -arm --filter "Benchstone.BenchF.Romber"

[AndyAyersMS]

I can never get egorbot syntax right the first time.

[AndyAyersMS]

@EgorBot -intel -arm --filter Benchstone.BenchF.Romber.Test