JDK-8288317 : Enhance C1 regalloc diagnostics to assert hidden control flow
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18,19,20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-06-13
  • Updated: 2022-06-14
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 :  
Relates :  
Description
There were quite a few cases where the control flow hidden from C1 regalloc ran the into miscompilations. See for example JDK-8211231, JDK-8288303. It would be good to somehow assert these things in C1 more reliably.
Comments
The problem is actually with the spills that may be inserted between the branch targets. For example: if cond then L1 spill(something) L1: restore(something) If you jump to L1, then the spill is not going to happen and you're going to restore garbage. So may be what we need is to teach the allocator not to spill between these labels. Or mark these sections for the allocator in some special way.
14-06-2022

That's understood; yet it is opaque for those who write C1 intrinsics. C1 RA still sees the "normal" basic block boundaries, right? So maybe we can assert there are no branches within the basic blocks, and maybe specially exempt a few cases where it is safe to have branches, like in trivial intrinsics?
13-06-2022

It's not that you cannot emit control flow in a block, it's just that the RA will not treat it as control flow. From the stand point of the RA it's really a straight line code - it doesn't see these branches.
13-06-2022