RFR: 8364766: C2: Improve Value() of DivI and DivL for non-constant inputs [v7]

[Hannes Greule]

On Sun, 19 Oct 2025 19:15:06 GMT, Tobias Hotz <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/IntegerDivValueTests.java line 55:
>> 
>>> 53:         // All constants available during parsing
>>> 54:         return getIntConstant(50) / getIntConstant(25);
>>> 55:     }
>> 
>> Could you also add a test with randomly generated constants? Then you also don't need to use `getIntConstant` here. It would also make sense to write a short comment for `getIntConstant` to clarify why it's needed.
>> 
>> When dividing by a constant you might also want to make sure that other nodes generated in `transform_int/long_divide` also aren't present here anymore. I'd also assume that e.g., `v / C > Integer.MAX_VALUE / C` for a positive constant C wouldn't be fully optimized away due to https://bugs.openjdk.org/browse/JDK-8366815, can you confirm that?
>
> I've changed this test to use random constants and added random constants.
> Together with stricter IR verification, I also found two cases where JDK-8366815 actually causes two long division to not constant fold due to the transformation being too eager. I've linked the issue in a comment on the two cases and disabled IR verification.

Interesting find! I'm wondering if division by a constant (but with a variable dividend) after idealization can *always* give a type as precise as your implementation. I.e., you divide by 12 in the `testIntRange` test, but this seems to already constant-fold on the current master branch. If your changes don't improve anything for constant divisors, that's still totally fine (because it helps with non-constant divisors, and such tests are still valuable to avoid regressions), but it would be interesting to know.

I created https://bugs.openjdk.org/browse/JDK-8370196 regarding the MulHiNode deficit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26143#discussion_r2443468855