JIT: clone array loops with stride > 57

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64

[AndyAyersMS]

Drop the blanket stride cap (stride < 58) in optDeriveLoopCloningConditions that previously rejected array loops whose post-step IV could exceed INT_MAX given Array.MaxLength. For larger strides emit a runtime arr.Length <= INT_MAX - s + 1 cloning condition; for small strides the implicit Array.MaxLength bound still suffices and no extra check is added.

Builds on similar work we added for spans in #129309.

[dotnet-policy-service]

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

[AndyAyersMS]

@dotnet/jit-contrib PTAL

There are no SPMI hits for this, but it feels like we should take this so the array and span cases are on an even footing (not "exact" because arrays have a smaller size limit and so can omit a check for smaller strides).

Eg if you span-wrap an array we should not suddenly start optimizing differently.

[Copilot]

Pull request overview

This PR updates CoreCLR JIT loop cloning to allow array loops with strides ≥ 58 by replacing the previous blanket rejection with a runtime overflow guard (arr.Length <= INT_MAX - s + 1, adjusted for <= tests and limit offsets) when needed.

Changes:

• Replace the prior stride cap for array-length loops with a conditional overflow guard for large strides (and keep span overflow guarding behavior consistent).
• Rework the array-length limit handling to compute/reuse a single ArrIndex for deref/zero-trip/overflow/limit conditions.
• Add new JIT tests covering array loops with large strides (e.g., 60 and 256) and a few related limit forms.

Reviewed changes

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

File	Description
src/coreclr/jit/loopcloning.cpp	Removes the hard stride rejection and emits an additional runtime overflow condition for large strides where necessary.
src/tests/JIT/opt/Cloning/LargeStride.cs	Adds functional tests exercising array loops with strides > 57 and a few related loop shapes.
src/tests/JIT/opt/Cloning/LargeStride.csproj	Adds the corresponding test project file following the existing pattern in this directory.

[EgorBo]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

[AndyAyersMS]

Probably isn't worth the effort, but here and in other cases we always conservatively use CORINFO_Array_MaxLength while GT_ARR_LENGTH can be used for strings as well and the max length is different there (a lot smaller).

Large known strides through arrays are rare, I suspect the same is also true for strings.

FWIW I also prototyped handing invariant but unknown strides but the only place this hit was in an FFT benchmark.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

[AndyAyersMS]

diffs one small diff on arm32, which is unexpected.

Let me investigate.

We clone this loop

[MethodImpl(MethodImplOptions.NoInlining)]publicstaticinttest_up_big(int[]a,ints,intx){intr=0;inti;for(i=1;i<s;i+=2147483647){r+=a[i];}returnr;}

and then later realize the fast clone is dead and end up almost back where we started. Seems like we could avoid all this but it's probably not worth the trouble.

[AndyAyersMS]

@EgorBo can you re-approve?

[AndyAyersMS]

/ba-g persistent timeouts on windows arm64