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

[Hannes Greule]

On Mon, 27 Oct 2025 06:49:08 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> 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.

@eme64 do you want me to merge master? I guess re-running tests then wouldn't hurt either.

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

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