RFR: 8366815: C2: Delay Mod/Div by constant transformation
Hannes Greule
hgreule at openjdk.org
Thu Oct 23 07:24:06 UTC 2025
On Thu, 23 Oct 2025 04:58:33 GMT, Emanuel Peter <epeter 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.
>
> src/hotspot/share/opto/divnode.cpp line 545:
>
>> 543:
>> 544: // Keep this node as-is for now; we want Value() and
>> 545: // other optimizations checking for this node type to work
>
> Do we only need `Value` done first on the `Div` node, or also on uses of it?
> It might be worth explaining it in a bit more detail here.
>
> If it was just about calling `Value` on the `Div` first, we could probably check what `Value` returns here. But I fear that is not enough, right? Because it is the `Value` here that returns some range, and then some use sees that this range has specific characteristics, and can constant fold a comparison, for example. Did I get this right?
So, the *main* reason why I'm including Div here is mainly because of #26143; before that the DivI/LNode::Value() is actually less precise than Value on the nodes created by `transform_int_divide`. With #26143, some results are more precise even for constant divisors. In such case, uses can benefit from seeing the (then) more precise range. (@ichttt found a case where the replacement fails to constant-fold, but that's just due to missing constant folding in MulHiLNode)
A secondary reason is other optimizations checking for Div inputs, though I didn't find any existing check that would actually benefit. There *might* be optimization opportunities that want to detect division, but that's just
Generally from what I've found the benefit is bigger for Mod nodes, because there calling Value on the replacements is significantly worse. And there we also encounter typical usages in combination with range checks.
Do you want me to expand both Div and Mod comments to cover more concrete benefits, depending on the operation?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27886#discussion_r2454163486
More information about the hotspot-compiler-dev
mailing list