JDK-8321109 : C2: Revisit !n->is_Type() bailout in PhaseIdealLoop::try_sink_out_of_loop()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22,23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-11-30
  • Updated: 2023-12-18
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-8319372 - C2 compilation fails with "Bad immediate dominator info"
Description
After the fix for JDK-8319372, which removed some better type information for CastIINode, we might be able to relax the added bailout constraint !n->is_Type(). This RFE should investigate if that's possible.

We should be careful about sinking CheckCastPPNodes which, however, should be fine after the fix for JDK-8276064. But we should double-check that.
Comments
Attached test case crashes with the bailout condition removed (it uses -XX:+StressGCM and has to be run a few times for the crash to reproduce). The reason is that when an array load is sunk, its control is changed to the projection that branches out of the loop. But if an identical dominating test is found, then the test in the loop is removed and the load becomes control dependent on the dominating test that can be above the range check for the array. This doesn't reproduce with the n->is_Type() bailout condition because it prevents the CastII of the array access to be sunk which prevents the array load from floating above the range check. The bailout condition could still be removed but this problem would have to be fixed.
18-12-2023