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

Francisco Ferrari Bihurriet fferrari at openjdk.org
Thu Aug 14 06:10:13 UTC 2025


On Wed, 13 Aug 2025 07:05:51 GMT, Christian Hagedorn <chagedorn 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
>
> Update looks good, thanks! I'll run some testing and report back again.
> 
>> Could you already find some examples, where this change gives us an improved IR? If so, you could also add it as IR test.
> 
> Just double-checking, were you able to find such a test which now improves the IR with the better type info and `CmpU` while we could not with the old code? Otherwise, you could also file a follow-up RFE.

Hi @chhagedorn,

I added the new tests in e6b1cb897d9c75b34744c7d24f72abcec9986b0b. One problem I'm facing is that I'm unable to generate `Bool` nodes with arbitrary `BoolTest` values. Even if I try the assert inversions I removed in 10e1e3f4f796d05dcd5c56bc2365d5d564d93952, C2 has preference for `BoolTest::ne`, `BoolTest::le` and `BoolTest::lt`. Instead of using `BoolTest::eq`, `BoolTest::gt` or `BoolTest::ge`, it swaps what is put in `IfTrue` and `IfFalse`.

Even if `javac` generates an `ifeq` and an `ifne` with the same inputs, instead of a single `CmpU` with two `Bool`s (`BoolTest::eq` and `BoolTest::ne`), I get a single `Bool` (`BoolTest::ne`) with two `If` (one of them swapping `IfTrue` with `IfFalse`). I guess this is some sort of canonicalization to enable further optimizations.

Do you know a way to influence the `Bool`'s `BoolTest` value? Or @rwestrel do you?

This means the following 8 cases are not really testing what they claim, but repeating other cases with `IfTrue` and `IfFalse` swapped:

* `testCase1aOptimizeAsFalseForGT[xm|mx]` (they should use `BoolTest::gt`, but use `BoolTest::le`)
* `testCase1bOptimizeAsFalseForEQ[xm|mx]` (they should use `BoolTest::eq`, but use `BoolTest::ne`)
* `testCase1bOptimizeAsFalseForGE[xm|mx]` (they should use `BoolTest::ge`, but use `BoolTest::lt`)
* `testCase1bOptimizeAsFalseForGT[xm|mx]` (they should use `BoolTest::gt`, but use `BoolTest::le`)

Even if we don't find a way to influence the `BoolTest`, the cases are still valid and can be kept (just in case the described behaviour changes).

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

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


More information about the hotspot-compiler-dev mailing list