RFR: 8367967: C2: "fatal error: Not monotonic" with Mod nodes [v3]

[Vladimir Ivanov]

On Tue, 23 Sep 2025 21:03:41 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 1209:
>> 
>>> 1207:   if (t2 == Type::TOP) { return Type::TOP; }
>>> 1208: 
>>> 1209:   // Mod by zero?  Throw exception at runtime!
>> 
>> The comment is a bit confusing. It's not the node itself which produces the exception, but a dominating zero check (inserted during parsing). So, if a divisor becomes 0, it means the node is effectively dead and can go away.  
>> 
>> Also, the node should go away anyway as part of CFG pruning of dead branches when corresponding guard goes away. 
>> 
>> BTW if there are cases when control is not eliminated, it may irrevocably break the IR causing crashes down the road (take a look at JDK-8154831 as an example). So, maybe it's safer to just rely on dead control pruning to eliminate effectively dead ModI/ModL nodes and assert that there are no effectively dead ModI/ModL nodes present after GVN pass is over.
>
> The comment comes from the original code before my change in #25254, where that path also returned `POS` but that wasn't monotonic with my changes anymore.
> 
>> So, if a divisor becomes 0, it means the node is effectively dead and can go away.
> 
> I think this check mostly comes down to CCP. We need to return *something* for a zero divisor, and that something has to be monotonic with subsequent wider inputs.
> 
> If you agree with that observation, I can change the comment to better reflect what's going on, e.g., `Mod by zero can be observed in PhaseCCP, return TOP to ensure monotonic results` (I'm open for other suggestions).

Thanks for the clarifications. I thought about it for some time, but as things work now, I don't see a better alternative except just ignoring 0 divisor case. So, please, proceed with the fix as it is now.

Alternatively, to improve robustness, a dead ModI/ModL can kill dependent control akin to what Roland did for Type nodes with JDK-8349479.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27408#discussion_r2380437024