JIT: extend loop cloning for span+stride>1 and ±const limits

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures

[AndyAyersMS]

Enable cloning of loops over Span when the stride s is greater than 1, guarded by a runtime limit <= INT_MAX - s + 1 condition on the increasing var-limit case. Other forms are already implicitly safe.

Extend MatchLimit to peel a constant offset off the limit so loops like

for(inti=0;i<span.Length-K;i+=K){ ...}

become clonable. Add a LimitOffset to NaturalLoopIterInfo that feeds into LC_Ident, the zero-trip / per-access / NE / overflow guards, and a new arr.Length + offset >= 0 guard (for very short array lengths and negative offsets).

[dotnet-policy-service]

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

[AndyAyersMS]

@EgorBo PTAL
fyi @dotnet/jit-contrib

Impacts ~200 methods across SPMI. If you know of specific cases that should be handled in BCL / etc let me know and I'll verify.

[AndyAyersMS]

Also want to see if IV opts can now understand the IV does not overflow in the fast path.

[Copilot]

Pull request overview

This PR extends CoreCLR JIT loop cloning’s ability to reason about loop limits and spans by (1) modeling limitBase ± const limits as a base + offset and (2) enabling span-based loop cloning for non-unit strides with an added overflow safety guard. It also adds new JIT tests that exercise non-unit stride span loops and offset limits like Length - K.

Changes:

• Add NaturalLoopIterInfo::LimitOffset plus LimitBase() to represent and consume base ± const loop limits.
• Extend LC_Ident to carry an offset for Var and ArrAccess, and plumb it through condition generation.
• Update loop cloning condition derivation to support span stride > 1 (increasing loops) with an overflow bound, and add a guard for negative arr.Length + offset limits; add new tests for these scenarios.

Reviewed changes

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

Show a summary per file

File	Description
src/coreclr/jit/compiler.h	Adds LimitOffset and declares LimitBase() on NaturalLoopIterInfo.
src/coreclr/jit/flowgraph.cpp	Implements limit peeling into LimitOffset, adds debug printing, and implements LimitBase(); updates limit accessors to use it.
src/coreclr/jit/loopcloning.h	Extends LC_Ident with offset and updates equality/printing/constructors.
src/coreclr/jit/loopcloning.cpp	Materializes LC_Ident offsets, enables span stride>1 cloning with an overflow guard, and threads LimitOffset into emitted conditions.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.csproj	New JIT test project for span non-unit stride cloning scenarios.
src/tests/JIT/opt/Cloning/SpanNonUnitStride.cs	New tests covering span loops with stride 2/3 and various comparison forms.
src/tests/JIT/opt/Cloning/OffsetLimit.csproj	New JIT test project for limit-offset recognition scenarios.
src/tests/JIT/opt/Cloning/OffsetLimit.cs	New tests covering Length - K, SIMD-count offsets, and related limit forms.

[tannergooding]

Will this also work for cases like:

for(inti=0;i>=0&&i<arr.Length;i+=K){ ...}// or its functional equivalentfor(inti=0;(uint)i<(uint)arr.Length;i+=K){ ...}

In both cases, overflow can happen but the guard check ensures that i cannot be 0, so it must also be safe and so the arr.Length - K shouldn't be required.

[AndyAyersMS]

We already handled arrays with K less than 58 because the max array length limits limit when overflow can happen (I'll double check for your cases just to be sure).

This PR enables something similar for span where there aren't those same guarantees. (will edit the commit comment).

[AndyAyersMS]

Note

AI-generated comment.

Prototyped the IV no-overflow analysis as a follow-up (draft branch iv-no-overflow-from-dom). The new code does let SCEV prove the fast clone's IV cannot overflow using the cloning guard, but it does not yet unblock strength reduction or downcounting on stride>1 loops: SCEV's trip-count formula at scev.cpp:2093 still requires |step| == 1 (the standing TODO about adding a division operator), and a secondary lower-bound proof (step <= rhs + 1) goes via optRelopImpliesRelop which doesn't bridge additive transforms. Parking the change until those two are addressed.

[AndyAyersMS]

Turns out we can't yet handle

 for (int i = 0; i >= 0 && i < arr.Length; i += K) { ... }

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

[AndyAyersMS]

The other case is handled provided K <= 57. I suppose we could now extend it (and arrays in general to larger K with extra cloning checks like we're doing here for spans).

I will do that as a follow-on PR.

[tannergooding]

Just to be clear, I don't think this is pressing for this PR, more just an interest as to what we are and aren't covering at this point.

because the loop has two exit edges when we analyze it for cloning. Do you think this pattern is common?

I'm not sure exactly how common it is, but it's one of the patterns that I've seen users write for SIMD code.

In general I'd prefer if users didn't have to write stuff like (uint)i <= (uint)span.Length, as I think its functionally harder to reason about than i >= 0 && i < span.Length, where you don't have to think about "this is two's complement, so negatives become large positives, so it is safe".

But, due to historical JIT pessimizations, we have a lot of our own code and have pushed users towards the casting pattern instead. I think we even have a pass that transforms the i >= 0 && i < span.Length check into (uint)i <= (uint)span.Length in the JIT, but it might be happening after we do the loop checks.

[tannergooding]

Changes look good/correct to me. Left a small comment about a potential future opt (not a priority) and a question about whether a given handling path is necessary since morph should canonicalize most trees.

[AndyAyersMS]

diffs

More like 300 methods impacted. More cloning, more "unprofitable rejected" cloning.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[AndyAyersMS]

Failures are #129027, #129329

[JulieLeeMSFT]

Reviewed flow graph and loop cloning changes. LGTM on adding the new LimitOffset to make loops for span clonable. It checks (span.Length >= K and no-overflow on i + stride) for Span.

[AndyAyersMS]

/ba-g known failures