JIT: fix bug in loop cloning with down-counting loops#126770
JIT: fix bug in loop cloning with down-counting loops#126770AndyAyersMS merged 1 commit intodotnet:mainfrom
Conversation
We were not creating proper cloning conditions, so the fast path might execute in cases where it shouldn't. We need to always verify for down counting that the initial value is strictly less than the array length(s).
|
@jakobbotsch PTAL |
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Pull request overview
Fixes an issue in CoreCLR JIT loop cloning where down-counting loops could generate overly-permissive fast-path conditions, allowing bounds-check removal when the initial index equals the array/span length.
Changes:
- Tighten loop cloning limit condition derivation for down-counting loops to require the initial iterator value be strictly less than the relevant length.
- Add new JIT regression tests covering down-counting loops that start at
Lengthfor both arrays and spans. - Add a dedicated test project for the new regression test.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/coreclr/jit/loopcloning.cpp | Adjusts derived cloning condition operator so down-counting loops require init < length rather than allowing init == length. |
| src/tests/JIT/opt/Cloning/DownCounted.cs | Adds regression coverage for array and span down-counting loops that should throw on a[Length] unless cloning conditions are correct. |
| src/tests/JIT/opt/Cloning/DownCounted.csproj | Adds a minimal test project definition consistent with other tests in the directory. |
Comments suppressed due to low confidence (1)
src/tests/JIT/opt/Cloning/DownCounted.cs:73
- There are extra blank lines (including whitespace-only lines) at the end of the file. Please trim trailing whitespace / remove the extra blank lines to keep diffs clean and comply with typical repo formatting rules.
}
|
The SPMI report is empty because we're just changing a branch condition, so the binary sizes are the same. |
|
/backport to release/10.0 |
|
Started backporting to |
|
/backport to release/9.0 |
|
Started backporting to |
|
/backport to release/9.0-staging |
|
Started backporting to |
|
/backport to release/8.0-staging |
|
Started backporting to |
… loops (#126914) Backport of #126770 to release/8.0-staging /cc @AndyAyersMS ## Customer Impact - [x] Customer reported - [ ] Found internally JIT optimizations can cause certain down-counting loops to bypass a bounds check. Code that normally would throw index out of bounds exceptions on an array store might instead corrupt the heap. In particular the loop must have unknown upper bound and have a shape like: ```c# for (int i = N; i > 0; i--) { a[i] = ...; } ``` and then be invoked in a context where `N` is exactly `a.Length`. The loop exiting predicate must be `>` and not `>=`. In such cases the code will write to `a[N]` which is beyond the extent of `a`. Customer impact is likely low. Correct behavior here is to throw an exception. ## Regression - [x] Yes - [ ] No Introduced in .NET 7 with #67930. ## Testing Verified fix on repro case. SPMI had 132 method contexts with diffs from the fix change. Inspected a few and most either had redundant guards beforehand or else were only reading from the arrays. ## Risk Low, changes the code that decides at runtime if execution can use a "cloned" loop that omits bounds checks; now we are correctly cautious about running the fully checked loop.. Co-authored-by: Andy Ayers <andya@microsoft.com>
… loops (#126913) Backport of #126770 to release/9.0-staging /cc @AndyAyersMS ## Customer Impact - [x] Customer reported - [ ] Found internally JIT optimizations can cause certain down-counting loops to bypass a bounds check. Code that normally would throw index out of bounds exceptions on an array store might instead corrupt the heap. In particular the loop must have unknown upper bound and have a shape like: ```c# for (int i = N; i > 0; i--) { a[i] = ...; } ``` and then be invoked in a context where `N` is exactly `a.Length`. The loop exiting predicate must be `>` and not `>=`. In such cases the code will write to `a[N]` which is beyond the extent of `a`. Customer impact is likely low. Correct behavior here is to throw an exception. ## Regression - [x] Yes - [ ] No Introduced in .NET 7 with #67930. ## Testing Verified fix on repro case. SPMI had 132 method contexts with diffs from the fix change. Inspected a few and most either had redundant guards beforehand or else were only reading from the arrays. ## Risk Low, changes the code that decides at runtime if execution can use a "cloned" loop that omits bounds checks; now we are correctly cautious about running the fully checked loop. Co-authored-by: Andy Ayers <andya@microsoft.com>
…126885) Backport of #126770 to release/10.0 /cc @AndyAyersMS ## Customer Impact - [x] Customer reported - [ ] Found internally JIT optimizations can cause certain down-counting loops to bypass a bounds check. Code that normally would throw index out of bounds exceptions on an array store might instead corrupt the heap. In particular the loop must have unknown upper bound and have a shape like: ```c# for (int i = N; i > 0; i--) { a[i] = ...; } ``` and then be invoked in a context where `N` is exactly `a.Length`. The loop exiting predicate must be `>` and not `>=`. In such cases the code will write to `a[N]` which is beyond the extent of `a`. Customer impact is likely low. Correct behavior here is to throw an exception. ## Regression - [x] Yes - [ ] No Introduced in .NET 7 with #67930. ## Testing Verified fix on repro case. SPMI had 132 method contexts with diffs from the fix change. Inspected a few and most either had redundant guards beforehand or else were only reading from the arrays. ## Risk Low, changes the code that decides at runtime if execution can use a "cloned" loop that omits bounds checks; now we are correctly cautious about running the fully checked loop. Co-authored-by: Andy Ayers <andya@microsoft.com>
We were not creating proper cloning conditions, so the fast path might execute in cases where it shouldn't.
We need to always verify for down counting that the initial value is strictly less than the array length(s).