JDK-8265784 : [C2] Hoisting of DecodeN leaves MachTemp inputs behind
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 11,17
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- CPU: ppc,s390x
- Submitted: 2021-04-22
- Updated: 2021-05-12
- Resolved: 2021-05-04
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.
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 11 | JDK 17 |
|---|---|
| 11.0.12Fixed | 17 b21Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
C2's Local Code Motion (LCM) can hoist DecodeN nodes into a different block. Depending on CompressedOops mode and platform, they can have MachTemp input nodes representing temp registers as needed by the platform code and /or other input nodes. PPC64 and s390 have DecodeN implementations which use a MachTemp input. When LCM hoists the DecodeN, they reside in the old block, but should get hoisted together with the DecodeN node. Load Base is a further possible input node (e.g. on s390). This can be observed by the new assertion introduced by JDK-8263227 when running e.g. compiler/runtime/Test6826736.java. Crashes are not observed in product build. However, the register allocation may produce sub-optimal results.
Comments
|