Use SSA-based TryGetRange to fold conditions#129354
Open
EgorBo wants to merge 3 commits into
Open
Conversation
github-actions
Bot
added
the
area-CodeGen-coreclr
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends JIT assertion propagation to opportunistically fold ordered integer relational operators (<, <=, >, >=) to constant true/false using the SSA-based RangeCheck::TryGetRange analysis, and adds a small constant fast-path in TryGetRange itself to make such queries cheaper.
Changes:
- Add a constant fast-path to
RangeCheck::TryGetRangefor int/nint constants that fit inint32. - In
optAssertionPropGlobal_RelOp, when assertion-based range evaluation can’t prove a relop constant, attempt SSA-based operand range discovery viaTryGetRangeand fold when the relop becomes provably constant.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/jit/rangecheck.cpp | Adds a fast-path for constant expressions in RangeCheck::TryGetRange. |
| src/coreclr/jit/assertionprop.cpp | Adds SSA-based range evaluation to fold certain ordered relops during global assertion propagation. |
Member
Author
|
/azp list |
This comment was marked as resolved.
This comment was marked as resolved.
Member
Author
|
/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-coreclr libraries-pgo, Fuzzlyn |
|
Azure Pipelines successfully started running 4 pipeline(s). |
…ed type The VNF_Cast handling in RangeCheck::GetRangeFromAssertionsWorker reused the source-type range for any widening cast, assuming the value is preserved. That is wrong when widening a signed source into a smaller-than-int unsigned type (e.g. (ushort)(sbyte)): negative source values are zero-extended into large positive values ((ushort)(-1) == 65535), so the source range no longer bounds the result. The new SSA-based relop folding then folded conditions such as 30997 > (ushort)s_F3 to a wrong constant. Use the destination-type range in that case. Found by Fuzzlyn. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run Fuzzlyn |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
PTAL @AndyAyersMS @dotnet/jit-contrib see description |
EgorBo
commented
Jun 15, 2026
| // RangeCheck does not understand reads through LCL_FLD nodes: a LCL_FLD use reads a | ||
| // sub-range of the local (a different offset and/or a narrower type), so the value | ||
| // produced by the (full-width) definition does not describe the value being read. | ||
| if (lclUse->OperIs(GT_LCL_FLD)) |
Member
Author
There was a problem hiding this comment.
a correctness issue I found as part of this PR.
EgorBo
commented
Jun 15, 2026
| // signed source into a smaller-than-int unsigned type (e.g. (ushort)(sbyte)). There, negative | ||
| // source values are zero-extended into large positive values (e.g. (ushort)(-1) == 65535), so | ||
| // the source range no longer bounds the result. | ||
| bool widensToSmallUnsigned = varTypeIsUnsigned(castToType) && |
Member
Author
There was a problem hiding this comment.
another pre-existing correctness issue we had
AndyAyersMS
approved these changes
Jun 15, 2026
| assert(block != nullptr); | ||
| assert(tree != nullptr); | ||
|
|
||
| int budget = 64; |
Member
There was a problem hiding this comment.
How do we arrive at these budget values?
Member
Author
|
/azp run Fuzzlyn |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Diffs (~ -1.2Mb on linux-x64)
We have two ways of computing a
Range {int lo;int hi}for a tree:GetRangeFromAssertions(purely on top of VN and assertions, handles PHIs as well)TryGetRange- SSA-based approach + assertions +GetRangeFromAssertions, used for GT_BOUNDS_CHECK only today.This PR enables
TryGetRangefor folding relops in global assertion prop. The TP Impact is 0.3-0.4% on average, I have some ideas how to improve it inside RangeCheck, but I think it's worth it.Mainly, it helps folding various Span.Slice checks we don't use GT_BOUNDS_CHECK for.
NOTE: we don't set preferred bound yet when we call it, I'll experiment with that separately.