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

[Vladimir Ivanov]

On Fri, 24 Oct 2025 07:09:25 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.

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

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