Use SSA-based TryGetRange to fold conditions by EgorBo · Pull Request #129354 · dotnet/runtime

EgorBo · 2026-06-12T22:52:27Z

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 TryGetRange for 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.

dotnet-policy-service · 2026-06-12T22:53:47Z

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 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::TryGetRange for int/nint constants that fit in int32.
In optAssertionPropGlobal_RelOp, when assertion-based range evaluation can’t prove a relop constant, attempt SSA-based operand range discovery via TryGetRange and 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.

Copilot

Pull request overview

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

Copilot

Pull request overview

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

EgorBo · 2026-06-14T14:18:43Z

/azp list

EgorBo · 2026-06-14T14:19:57Z

/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-coreclr libraries-pgo, Fuzzlyn

azure-pipelines · 2026-06-14T14:20:24Z

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>

EgorBo · 2026-06-15T12:24:23Z

/azp run Fuzzlyn

azure-pipelines · 2026-06-15T12:24:36Z

Azure Pipelines successfully started running 1 pipeline(s).

Copilot

Pull request overview

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

EgorBo · 2026-06-15T17:23:53Z

PTAL @AndyAyersMS @dotnet/jit-contrib see description

AndyAyersMS

Nice improvements!

AndyAyersMS · 2026-06-15T18:43:57Z

+ assert(block != nullptr);
+ assert(tree != nullptr);
+
+ int budget = 64;


How do we arrive at these budget values?

Purely SPMI driven. RangeCheck currently has a budget for all operations while this makes it per-operation, e.g. 50 has a bad impact on improvements, 100 has a bad impact on TP

EgorBo · 2026-06-16T11:10:51Z

/azp run Fuzzlyn

azure-pipelines · 2026-06-16T11:11:06Z

Azure Pipelines successfully started running 1 pipeline(s).

In RangeCheck::GetRangeFromAssertionsWorker the range of a zero-extending (srcIsUnsigned) cast whose source is a signed small type (e.g. (uint)(sbyte), dumped as `CAST long <- ulong <- uint` of a TYP_BYTE) was taken from the unsigned small type, giving [0..255]. But small signed types are held sign-extended in their int-width slot, so (uint)(sbyte)(-1) == 0xFFFFFFFF, far outside [0..255]. Widen castFromType to the actual int source width so such casts fall back to an unknown range instead of an unsound small one. Fixes two pre-existing Fuzzlyn miscompiles where the bogus range made `3647 <= (uint)s` fold to false and a `% N` dividend look non-negative (signed long MOD converted to unsigned). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

BoyBaykiller · 2026-06-16T23:12:15Z

With this we finally get rid of the branch here :)

staticvoidTest(){for(inti=0;i<100;i++){if(i<0){Console.WriteLine("Hi");}}}

G_M54612_IG02: ;; offset=0x0000moveax,99align[0 bytes for IG03] ;; size=5 bbWeight=0.25 PerfScore 0.06G_M54612_IG03: ;; offset=0x0005deceaxjne SHORT G_M54612_IG03 ;; size=4 bbWeight=4 PerfScore 5.00G_M54612_IG04: ;; offset=0x0009ret ;; size=1 bbWeight=1 PerfScore 1.00

EgorBo · 2026-06-17T15:03:44Z

@AndyAyersMS I pushed another commit to fix a Fuzzlyn failure, but it likely was a pre-existing issue. But now it needs a new approval

tannergooding · 2026-06-17T17:11:13Z

 var_types castFromType = srcIsUnsigned ? varTypeToUnsigned(arg0Typ) : arg0Typ;

- if (genTypeSize(castFromType) < genTypeSize(castToType))
+ // A zero-extending cast (srcIsUnsigned) of a signed sub-int source is unsound to bound by the


Why is srcIsUnsigned for int -> sbyte -> uint?
sbyte -> T is always sign extending, regardless of target type. While byte -> T is always zero extending.
So, I would expect that (uint)(sbyte)(-1) to say the src is signed, at each cast step.
While for (int)(byte)(-1) I'd expect the -1 -> byte to be srcIsSigned and byte -> int to be srcIsUnsigned

sbyte -> T is always sign extending,
In that Fuzzlyn failure we end up with this:
[000040] OR long [000039] --CXG+---U- CAST long <- ulong <- uint // U = GTF_UNSIGNED [000038] --CXG+----- COMMA byte // s_19, an sbyte static field ... [000034] IND byte (static Fseq[s_19]
castToType=ulong srcIsUnsigned=1 arg0Typ=sbyte
like you said, sbyte source but with srcIsUnsigned == true.
We probably should refactor casts a bit to make it clearer when to rely on what. Maybe we should do what LLVM does - separate sext and zest and separate nodes.

Is that not a bug in VN or elsewhere here?
Presumably the actual issue is that we end up with VN information saying there is a zero-extension for a value that is signed and so we could end up with incorrect codegen in a few different ways.

Was this the same failure as in #129516? If so it was bisected to #128906

Yes, this change fixes #129516 and is not related to this PR, I fixed it because I didn't realize it was pre-existing on main and needed clean Fuzzlyn.
Is that not a bug in VN or elsewhere here?
I don't think so, it does look like a fallout artifact from enabling LONG for Ranges. srcIsUnsigned here isn't "the source is unsigned," it's the int -> long widening's extension mode VNF_Cast(byteVN, {long, │ srcIsUnsigned=true}) correctly means "zero-extend the 32-bit (sign-extended) operand," i.e. (long)(uint)(sbyte) .
Anyway, feel free to research it or if you believe it's not correct, for now it's a bug-fix for Fuzzlyn and judging by the diffs it doesn't make the impl conservative

Talked about it on discord a bit. So in this case the source is unsigned, i.e. the cast represents an unsigned extension and so it will take something like 0x8000_0000 and produce 0x0000_0000_8000_0000, not 0xFFFF_FFFF_8000_0000
The general issue is that there's a secondary implicit cast from sbyte->int which isn't necessarily captured and some tools may overlook if they presume the castOp->TypeGet() is the actual source type. -- We probably should carefully audit this or maybe have some CastNode->CastOpType or similar metadata to avoid this issue and ensure that we see TYP_INT instead of TYP_BYTE or similar.
That is, we have something rather like 0x80 -> 0xFFFF_FF80 -> 0x0000_0000_FFFF_FF80 (sbyte->int->uint->ulong), and not 0x80 -> 0x0000_0080 -> 0x0000_0000_0000_0080 (byte->int->uint->ulong) like it was being interpreted as. -- Just for completeness sake, the other case it theoretically could've been was 0x80 -> 0xFFFF_FF80 -> 0xFFFF_FFFF_FFFF_FF80if it wassbyte->int->long`

EgorBo · 2026-06-17T20:07:56Z

/ba-g timeouts

hez2010 · 2026-06-18T12:00:39Z

With this we finally get rid of the branch here :)

staticvoidTest(){for(inti=0;i<100;i++){if(i<0){Console.WriteLine("Hi");}}}

G_M54612_IG02: ;; offset=0x0000moveax,99align[0 bytes for IG03] ;; size=5 bbWeight=0.25 PerfScore 0.06G_M54612_IG03: ;; offset=0x0005deceaxjne SHORT G_M54612_IG03 ;; size=4 bbWeight=4 PerfScore 5.00G_M54612_IG04: ;; offset=0x0009ret ;; size=1 bbWeight=1 PerfScore 1.00

How about some SSA-based branch removal that can also figure out the loop ends up with a no-op then.

EgorBo · 2026-06-18T12:02:58Z

How about some SSA-based branch removal that can also figure out the loop ends up with a no-op then.

I think Jakob tried to implement a dead loop removal pass, but there were concerns regarding trivial dead endless loops

jakobbotsch · 2026-06-18T12:17:00Z

How about some SSA-based branch removal that can also figure out the loop ends up with a no-op then.
I think Jakob tried to implement a dead loop removal pass, but there were concerns regarding trivial dead endless loops

Yes, it was #103087 that we prototyped with @AndyAyersMS during the face to face a couple of years ago.

jakobbotsch · 2026-06-18T12:26:14Z

But this loop could be removed with a simple IV optimization. I think we need a different motivation than a random micro benchmark improving though, such dead loops seem to only be likely from benchmarks where it would just be annoying to do that optimization.

[Diffs](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1462451&view=ms.vss-build-web.run-extensions-tab) (~ -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 `TryGetRange` for 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. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CopilotAI review requested due to automatic review settings June 12, 2026 22:52

github-actionsBot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 12, 2026

dotnet-policy-serviceBot assigned EgorBo Jun 12, 2026

Copilotstarted reviewing on behalf of EgorBo June 12, 2026 22:52 View session

CopilotAI reviewed Jun 12, 2026
View reviewed changes

EgorBo marked this pull request as ready for review June 13, 2026 02:26

CopilotAI review requested due to automatic review settings June 13, 2026 02:26

Copilotstarted reviewing on behalf of EgorBo June 13, 2026 02:26 View session

CopilotAI reviewed Jun 13, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/assertionprop.cpp Outdated

This was referenced Jun 13, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
Multiple Helix work items fail on maccatalyst/tvos CoreCLR Release #126460
Closed
Arm/Arm64: Segfault in System.Security.Cryptography.Tests#129339
Closed

CopilotAI review requested due to automatic review settings June 13, 2026 12:19

Copilotstarted reviewing on behalf of EgorBo June 13, 2026 12:19 View session

CopilotAI reviewed Jun 13, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/assertionprop.cpp Outdated
Comment threadsrc/coreclr/jit/assertionprop.cpp Outdated

cleanup
5144397

EgorBo force-pushed the ssa-based-relop branch from d1283a6 to 5144397Compare June 13, 2026 14:25

Merge branch 'main' into ssa-based-relop
9a1efbc

This comment was marked as resolved.
Sign in to view

CopilotAI review requested due to automatic review settings June 15, 2026 12:24

Copilotstarted reviewing on behalf of EgorBo June 15, 2026 12:24 View session

CopilotAI reviewed Jun 15, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/assertionprop.cpp

EgorBo requested a review from AndyAyersMS June 15, 2026 17:23

EgorBo commented Jun 15, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/rangecheck.cpp

EgorBo commented Jun 15, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/rangecheck.cpp

AndyAyersMS approved these changes Jun 15, 2026
View reviewed changes

jakobbotsch mentioned this pull request Jun 17, 2026
JIT: Bad codegen with compare + cast #129516
Closed

JulieLeeMSFT linked an issue Jun 17, 2026 that may be closed by this pull request
JIT: Bad codegen with compare + cast #129516
Closed

EgorBo requested a review from AndyAyersMS June 17, 2026 15:03

AndyAyersMS approved these changes Jun 17, 2026
View reviewed changes

tannergooding reviewed Jun 17, 2026
View reviewed changes

EgorBo enabled auto-merge (squash) June 17, 2026 21:22

EgorBo merged commit 067b864 into dotnet:mainJun 17, 2026
134 of 139 checks passed

EgorBo deleted the ssa-based-relop branch June 17, 2026 21:23

dotnet-maestroBot mentioned this pull request Jun 18, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7280
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 18, 2026

EgorBo added the reduce-unsafe label Jun 26, 2026

github-actionsBot locked and limited conversation to collaborators Jul 27, 2026

Uh oh!

Conversation

EgorBo commented Jun 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Jun 12, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

EgorBo commented Jun 14, 2026

Uh oh!

This comment was marked as resolved.

EgorBo commented Jun 14, 2026

Uh oh!

azure-pipelinesBot commented Jun 14, 2026

Uh oh!

EgorBo commented Jun 15, 2026

Uh oh!

azure-pipelinesBot commented Jun 15, 2026

Uh oh!

CopilotAI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

EgorBo commented Jun 15, 2026

Uh oh!

Uh oh!

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

AndyAyersMSJun 15, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBoJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBo commented Jun 16, 2026

Uh oh!

azure-pipelinesBot commented Jun 16, 2026

Uh oh!

BoyBaykiller commented Jun 16, 2026

Uh oh!

EgorBo commented Jun 17, 2026

Uh oh!

tannergoodingJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBoJun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tannergoodingJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

AndyAyersMSJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBoJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

tannergoodingJun 17, 2026

Choose a reason for hiding this comment

Uh oh!

EgorBo commented Jun 17, 2026

EgorBo commented Jun 12, 2026•
edited
Loading

EgorBoJun 17, 2026•
edited
Loading