RFR: 8356813: Improve Mod(I|L)Node::Value

[Hannes Greule]

On Mon, 19 May 2025 16:00:48 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1229:
>> 
>>> 1227:   // Mod by zero?  Throw exception at runtime!
>>> 1228:   if (i2->is_con() && i2->get_con() == 0) {
>>> 1229:     return TypeInt::ZERO;
>> 
>> Like @merykitty , I am unsure of returning zero in this case. The original code probably returned TypeInt::POS for the same reason you bring up below:
>> 
>>> JVMS `irem` bytecode: "the result of the remainder operation can be negative only if the dividend is negative and can be positive only if the dividend is positive"
>> 
>> Hence, I would argue to keep that oldbehaviorr, since the result of a modulo with zero is not defined to be zero.
>> 
>> I like the idea of returning TOP, but that needs to be tested really well, since all uses of the modulo computation will get removed. I am not familiar enough with the type lattice to reason about the formal correctness of this.
>
>> The original code probably returned TypeInt::POS for the same reason you bring up below:
> 
> I doubt that, as it doesn't account for the sign of the dividend at all here. We also can't keep the existing behavior (see the section about monotonicity in the PR description).
> From my understanding, the node should also be kept alive no matter the value due to its control input. 
> 
> I'll test with returning TOP.

Using TOP seems to work, but I'm still a bit hesitant to use it:
- I'm not sure if it is intended to be used this way
- `TypeNode`s get a special handling when they become TOP. That is not a problem as long as the Mod nodes aren't `TypeNode`s, but it looks rather dangerous.

I think I'd still prefer to use ZERO unless someone else can guarantee that using TOP will be fine. I could maybe give a more in-depth explanation why ZERO behaves monotonic here as a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25254#discussion_r2106144665