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

[Emanuel Peter]

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.

Manuel and I discussed in the office a little more :)

Can you show us a concrete example, where `Div` gets `Idealized` early, and then the generated nodes do not propagate the value range sufficiently precise for the comparison to constant fold?

I suspect that it is the value range "truncation" on the lower bits that are lost in `MulHiLNode`, but it would be nice to see that example ;)

Because if there is a solution that just improves the `Value` of the mul/shift/... nodes, that would probably be preferable.

But if we in the end need to build a `Value` optimization that pattern matches again through the nodes that `transform_int_divide` generated, that would probably be less nice, given the complexity. And then we should do the delay.

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

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