RFR: 8375653: C2: CmpUNode::sub is not monotonic [v2]

[Emanuel Peter]

On Thu, 22 Jan 2026 05:21:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes the issue that `CmpUNode::sub` is not monotonic. The root cause is that it returns different values for several cases, but the cases are not mutually exclusive and the return values are not a subset of each other. This leads to the possibilities that a node satisfying both cases will return the first value, but if upon being widen it ceases to satisfy the first case but still satisfies the second case, the method will return the second value, which is not a superset of the previous result.
>> 
>> For example, given `r = CmpU(x, y)`.
>> 
>> At the first iteration, `type(x) = {0}` and `type(y) = {1, -1}`, then `CmpUNode::sub` returns `TypeInt::CC_LE` since it sees that `x` is the constant `0`.
>> 
>> At the second iteration, `type(x) = {0, 2}` and `type(y) = {-1, 1}`, then `CmpUNode::sub` returns `TypeInt::CC_NE` since it sees that `x` and `y` do not overlap. This is not a superset of `TypeInt::CC_LE`, which leads to an assertion.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A little more detailed explanation

@merykitty Thanks for the fix!
And: it is so much nicer to do unsigned ops now that we actually have unsigned types :)

It would indeed be nice if eventually we refactored the code such that gtests are possible. Is that not generally the plan?

I was also wondering: do we already have some good IR tests for `compareUnsigned`? It would be a shame if this led to a performance regression just because we don't have the coverage.

And: you should probably not just test `Integer.compareUnsigned`, but also `Long.compareUnsigned`, right?

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29308#pullrequestreview-3690927068