RFR: 8364970: Redo JDK-8327381 by updating the CmpU type instead of the Bool type [v2]

[Francisco Ferrari Bihurriet]

On Mon, 11 Aug 2025 10:15:11 GMT, Galder Zamarreño <galder at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply code review suggestions and add JBS to test
>
> Thanks for the PR @franferrax. Did you consider adding an IR test or similar that would expose the inconsistent state? Would it be feasible?

Hi @galderz,

I'm afraid I had to be a bit opaque because this was partially discussed in the VG.

I was just referring to the fact that the `CmpUNode` type was being kept as `TypeInt::CC`, while we know more than that:

* **1a.** `(x & m) <=u m` and `(m & x) <=u m` are always true, so `CmpU(x & m, m)` and `CmpU(m & x, m)` are known to be `TypeInt::CC_LE`
* **1b.** `(x & m) <u m + 1` and `(m & x) <u m + 1` are always true for `m != -1`, so `CmpU(x & m, m + 1)` and `CmpU(m & x, m + 1)` are known to be `TypeInt::CC_LT` (when `m != -1`)

In both cases the `BoolNode` type was being changed to `TypeInt::ONE` but we weren't updating the `CmpUNode` type. So the `BoolNode` was incorporating the 1a/1b knowledge while the `CmpUNode` was not (that is the "inconsistency").

Since a `BoolNode` with `TypeInt::ONE` is removed, I don't know if there is a way to check the mentioned inconsistency with an IR test. What we do have is the reproducer for a56cd371a2c497e4323756f8b8a08a0bba059bf2, feel free to reach me internally for further details.

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

PR Comment: https://git.openjdk.org/jdk/pull/26666#issuecomment-3177551843