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

[Emanuel Peter]

On Fri, 24 Oct 2025 18:04:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> @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?
>
>> Do you consider the "expanded" versions of Div/Mod as a "different representation of Div/Mod"?
> 
> Yes, exactly.
> 
>> 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 https://github.com/openjdk/jdk/pull/27886#issuecomment-3436423466. Do you think that is a good idea?
> 
> Sure, It may be way above the complexity budget we are willing to spend on it. The expansion code I see for Div/Mod nodes doesn't look too complicated, but matching the pattern may require more effort. The positive thing is it'll optimize the pattern irrespective of the origin (either expanded Div/Mod or explicitly optimized in the code by the user). So, the question is how much complexity it requires vs scenarios it covers.
> 
>> 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?
> 
> It's not fully clear to me what is the scope of problematic scenarios. If it's only about Ideal() expanding the node before Value() has a chance to run, then wrapping the result of expansion in CastII/CastLL node and attach Value() as it's type should be enough (when produced type is narrower than Type::INT). 
> 
> If we want to to keep expanded shape while being able to compute its type as if it were the original node, then a new flavor of Cast node may help. The one which keeps the node type and its inputs and can run Value() as if it were the original node.

@iwanowww I see, so we could implement something like a `CastII` with multiple inputs, which we know must all be identical at runtime. The first input is the one we will in the end pick. But during `Value`, we take the intersection of all input ranges. So if another (not the first input) has a narrower type, we can use that type. I suppose that would be feasible. Do you have a good name for such a node?

What I don't know: how does that interact with other IGVN optimizations, especially those that want to pattern match specific nodes? Inserting such special cast nodes could interrupt `Ideal` optimizations, current pattern matching would not know how to deal with it. Probably it is not a big issue, but I'm not sure.

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

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