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

[Emanuel Peter]

On Thu, 23 Oct 2025 19:27:05 GMT, Vladimir Ivanov <vlivanov 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.
>
> It seems the root cause is a divergence in functionality in GVN between different representations of Div/Mod nodes.
> 
> How hard would it be to align the implementation and improve GVN handling for other representations, so the same type is constructed irrespective of the IR shape?
> 
> Alternatively, as part of the expansion, new representation can be wrapped in CastII/CastLL with the narrower type of original Div/Mod node.

@iwanowww I'm not quite following your suggestions / questions.

> It seems the root cause is a divergence in functionality in GVN between different representations of Div/Mod nodes.

> How hard would it be to align the implementation and improve GVN handling for other representations, so the same type is constructed irrespective of the IR shape?

Do you consider the "expanded" versions of Div/Mod as a "different representation of Div/Mod"?
If yes: we could pattern match for such "expanded" versions of Div/Mod, but it would be quite complex: you would have to parse through patterns like displayed [up here](https://github.com/openjdk/jdk/pull/27886#issuecomment-3436423466). Do you think that is a good idea? I already mentioned the idea [up here](https://github.com/openjdk/jdk/pull/27886#issuecomment-3435782079), but did not think it was desirable due to the complexity.

> Alternatively, as part of the expansion, new representation can be wrapped in CastII/CastLL with the narrower type of original Div/Mod node.

How does this "wrapping" help? After parsing, the CastII at the bottom of the "expanded" Div would just have the whole int range. How would the type of the CastII ever be improved, without pattern matching the "expanded" Div?

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

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