JDK-8343067 : C2: revisit constant-offset AddP chains after successful input idealizations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-10-25
  • Updated: 2024-11-11
  • Resolved: 2024-11-11
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.
JDK 24
24 masterFixed
Related Reports
Relates :  
Relates :  
Description
A successful idealization of the offset input of an AddP node n might replace n->in(AddPNode::Offset) with a constant, potentially enabling further optimization by AddPNode::Ideal() if n is used by another AddP node m with a constant offset. To enable this within an IGVN run, this pattern should be detected and m pushed into the IGVN worklist in PhaseIterGVN::add_users_of_use_to_worklist().

The attached TestAddPChain.java file (extracted from a mainline test case) illustrates the missing optimization. When running it with:
java -Xcomp -XX:CompileOnly=TestAddPChain::test TestAddPChain.java
we get subgraphs like StoreL(AddP(AddP(ConL), ConL)) (see unoptimized-subgraph.pdf), which in x64 requires materializing one of the constants in a register:

movl	$0x4, %r9d
...
movq	%rcx, 0x14(%rsi,%r9)

If the pattern is detected and the lowest AddP node is added to IGVN's working list (see draft patch attached), after AddPNode::Ideal() we get the expected StoreL(AddP(ConL)) subgraph, which in x64 can be implemented as part of the store's address computation:

movq	%r8, 0x18(%rbx)
Comments
Changeset: ec13364c Branch: master Author: Roberto CastaƱeda Lozano <rcastanedalo@openjdk.org> Date: 2024-11-11 10:05:15 +0000 URL: https://git.openjdk.org/jdk/commit/ec13364cdab5a52f704bc5d1575f3da17380b4f2
11-11-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21898 Date: 2024-11-05 10:02:16 +0000
05-11-2024

It would be nice if such cases would be caught by IGVN verification (see JDK-8298951 and related RFEs), i.e., something similar to JDK-8298952.
28-10-2024