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

[Tobias Hotz]

On Sun, 19 Oct 2025 12:31:06 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Tobias Hotz has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adjust long constant folding test as well
>>  - Adjust test, assert and comments
>
> src/hotspot/share/opto/divnode.cpp line 651:
> 
>> 649:   if( (t1 == bot) || (t2 == bot) ||
>> 650:       (t1 == Type::BOTTOM) || (t2 == Type::BOTTOM) )
>> 651:     return bot;
> 
> I think this can be removed - and in cases where one side is the local bottom (i.e., `TypeInt::INT`) and the other is more restricted, the result should even more precise after removing. Could you also add tests for such cases? For example dividing `TypeInt::INT` by some interval with a lower bound of 2, the resulting range can be narrowed. Similarly, dividing some small interval `[lo, hi]` by `TypeInt::INT` should result in a similar interval with bounds adjusted to deal with sign changes. If I didn't miss something, your code should already be able to deal with this, it's just this early return here preventing it.

I think you are correct. The only part where I am not sure is if every instance where i1/i2 can be Type::BOTTOM, i1/i2 can be cast to TypeInt.
Can someone please confirm the removal is safe?

> 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.

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

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