RFR: 8366815: C2: Delay Mod/Div by constant transformation

[Hannes Greule]

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

> The test cases show examples of code where `Value()` previously wasn't run because idealization took place before, resulting in less precise type analysis.
> 
> Please let me know what you think.

> Thinking about it a bit more, I think your fix is too superficial. If the discovery of the constant is slightly delayed, nothing is folded again. Consider the followig program for an example:
> 
> ```java
> class Test {
>     static boolean test(int x, boolean flag) {
>         Integer a;
>         if (flag) {
>             a = 171384;
>         } else {
>             a = 2902;
>         }
> 
>         return x % a >= a;
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 20000; i++) {
>             if (test(i, false)) {
>                 throw new RuntimeException("wrong result");
>             }
>         }
>     }
> }
> ```
> 
> In my opinion, the benefits do not outweigh the drawbacks for this PR. A better solution would probably be to delay the expansion of the Mod and Div nodes to post-loop optimizations and extend Superword to expand Div/Mod nodes to shifts. However, this is quite a bit of complexity, which raises if this complexity is worth it (@eme64 probably has opinions and/or guidance on this).

I'm not sure about the drawbacks here, but I think optimizing this on the superword level doesn't make things less complicated.

If cases where we end up idealizing before calling Value are a more general problem, I'd say it's worth to also address it on exactly that level: make sure that Value is called before Ideal. I'm just hesitant because I'm not aware of any other situations where this matters. One middle ground here would be some kind of `Node::InitialValue(...)` (or a better name :) ) that just calls `bottom_type()` by default and can be overridden for nodes like Mod and Div. Joining that value with the Value calculated later would solve this problem on a different level, but more effectively. But it would also be a more invasive change overall.

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

PR Comment: https://git.openjdk.org/jdk/pull/27886#issuecomment-3433611940