JDK-8366815 : C2: Delay Mod/Div by constant transformation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-09-03
  • Updated: 2025-10-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8282365 - Consolidate and improve division by constant idealizations
Relates :  
JDK-8356813 - Improve Mod(I|L)Node::Value
Relates :  
JDK-8286679 - more range check elimination for hash tables
Relates :  
JDK-8370135 - C2: Reconsider Mersenne number modulo optimization
Description
C2 employs optimizations to replace ModI/L DivI/L by a row of shifts, additions, multiplications, and subtractions if the divisor is a constant that isn't a power of 2. This is great for performance, but prevents some other optimizations:

- CmpUNode::sub() uses CmpUNode::is_index_range_check() to optimize ((X ModI Y) CmpU Y) patterns (for appropriate input ranges). As the ModI gets replaced too early, the range check is not eliminated if the size of an array is known to be constant.
- After JDK-8356813, ModI will provide better type information. But as Value() is only called after Ideal() in GVN, we don't call ModINode::Value() if the node is replaced beforehand. The replacement provides less precise type information, also preventing other (range check) optimizations.

Therefore I suggest delaying the transformation so other optimizations depending on finding a Mod node or on precise type information.

I'm not sure what the best way is there, so I'll leave this for someone else.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27886 Date: 2025-10-19 15:46:06 +0000
19-10-2025
[~epeter] I have encountered test failures when delaying until after loop-opts, due to missed vectorization opportunities, namely compiler.c2.cr7200264.TestIntVect test_divc and test_divc_n. I'll open a PR soon with delaying until IGVN.
17-10-2025
[~hgreule] Yes, seems like Matcher::use_asm_for_ldiv_by_con can be cleaned up! Do you want to file an RFE and do that? > Doing magic constant computation at runtime sounds similar to what libdivide does. But I guess that involves some more complexity :) Yes, it could be a little complicated. > I also noticed that even constants of the form 2^k trip up type analysis currently. > ... but I wonder if this is still beneficial on current platforms ... I don't really have time to investigate here. But if you think it might be worth investigating and have the time, then I'd be happy to look at your findings :)
15-09-2025
[~epeter] doing magic constant computation at runtime sounds similar to what libdivide does. But I guess that involves some more complexity :) I also noticed that even constants of the form 2^k trip up type analysis currently. And ModI/L currently also replaces 2^k - 1 by a chain of other operations for k >= 6. It looks like the benefit is that it doesn't require multiplyHigh (or int->long), but I wonder if this is still beneficial on current platforms (especially for lower k's, the produced chain seems to be longer than the more generic approach, at least for int). There also seems to be Matcher::use_asm_for_ldiv_by_con which currently returns false on all platforms from what I've found. Maybe that's worth being cleaned up too?
14-09-2025
[~hgreule] I think delaying would make sense. I think we may want to delay it even until after loop-opts. I have a related idea: If we mod/divide by a loop-invariant (and there are on average sufficient iterations), we could do the magic constant computation before the loop, and then use them to do shift/add/mul/sub inside the loop. This would require us to generate C2 IR instead of doing the computation in C++, as we are doing currently. [~qamai] What do you think about this idea? Related to your JDK-8282365
09-09-2025