-
Bug
-
Resolution: Fixed
-
P3
-
11, 17
-
b21
-
ppc, s390x
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8267029 | 11.0.12 | Martin Doerr | P3 | Resolved | Fixed | b02 |
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 byJDK-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.
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
Crashes are not observed in product build. However, the register allocation may produce sub-optimal results.
- backported by
-
JDK-8267029 [C2] Hoisting of DecodeN leaves MachTemp inputs behind
-
- Resolved
-
- relates to
-
JDK-8263227 C2: inconsistent spilling due to dead nodes in exception block
-
- Resolved
-
-
JDK-8051805 C2: MachTemp nodes not always in same block as their "use" node
-
- Open
-