More precise range assertions for GT_CNS_INT

[adamperlin]

Fixes #121400; We can use a simple binary search approach to narrow the upper bound for GT_CNS_INT type nodes in assertionprop. Credit for the approach to the comment here: #120980 (comment)

[dotnet-policy-service]

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 refines the range computation for integral constant nodes (GT_CNS_INT/GT_CNS_LNG) in JIT assertion propagation by selecting a narrower rangeType based on the constant’s magnitude, enabling tighter derived non-negative range assertions.

Changes:

• Replace coarse FitsIn<int32_t>/FitsIn<uint32_t> range typing with a more granular threshold-based selection (8/16/32-bit signed/unsigned) for constants.
• Use the selected narrower type’s maximum to tighten the inferred upper bound when the constant is known non-negative.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/coreclr/jit/assertionprop.cpp:346

• The GT_CNS_INT/GT_CNS_LNG switch case no longer returns or breaks after computing rangeType. This causes an unintended fallthrough into case GT_QMARK, where node->AsQmark() will be called on a constant node (invalid cast / potential crash). Add the missing return (or a break plus an appropriate return) after selecting the tighter rangeType.

        }

        case GT_QMARK:
            return Union(ForNode(node->AsQmark()->ThenNode(), compiler),
                         ForNode(node->AsQmark()->ElseNode(), compiler));

[Copilot]

Pull request overview

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

[adamperlin]

I will word this better.

[adamperlin]

SuperPMI status isn't loading for me now, but diffs looked small but positive. We have cases where we were emitting overflow checks for small constants that provably can't overflow, and this helps with some of those. The one concern I had was there appears to be a regression in the AssertionPropOverflow metric. I wouldn't want to create a ton of small range assertions here that aren't gaining us a massive amount.

[EgorBo]

@MihuBot -nuget

[EgorBo]

TBH, I don't think we should continue improving this function unless there is a strong motivation. It's IR based, I think it's better to rely on VN/SSA GetRange. IR based one is only helpful when IR is propagated directly (not saved to a local).

Your PR adds +40 LOCs of code with 0 diffs in MihuBot (huge number of contexts) and only 12 in a test collection in SPMI.
I think if we want to precisely track contstands, we should use #127675 approach

[adamperlin]

TBH, I don't think we should continue improving this function unless there is a strong motivation. It's IR based, I think it's better to rely on VN/SSA GetRange. IR based one is only helpful when IR is propagated directly (not saved to a local).

Your PR adds +40 LOCs of code with 0 diffs in MihuBot (huge number of contexts) and only 12 in a test collection in SPMI. I think if we want to precisely track contstands, we should use #127675 approach

This makes sense, we do want to be very careful about adding code without realistic impact. I'll close this one and the associated issue!