-
Bug
-
Resolution: Unresolved
-
P4
-
9, 10
-
generic
-
generic
In PhaseCFG::schedule_late(), there is code to keep MachTemp nodes in the same
block as their use, and in PhaseCFG::select() there is more code to keep MachTemp
nodes near their use. However, the MachTemp can still end up in a different block
from it use (call_catch_cleanup() is one function that can cause this.)
Since a MachTemp node doesn't actually emit any code, the register allocation for
it hasn't actually been initialized until the use node. Normally this is harmless,
but if the MachTemp is RegN, then any safepoint between the MachTemp and use
will add that RegN to the safepoint oopmap, which is fatal because the value is
uninitialized. Even if the MachTemp is not a RegN, having the MachTemp far away
from its use unnecessarily extends the live range of the register.
A possible fix for the general case would be to make sure that MachTemp
nodes are always placed just above their use in the same block.
A workaround for just the RegN case could be to treat RegN as RegI for MachTemp nodes.
To reproduce this problem, add a RegN TEMP to a rule like LoadN, CompareAndSwapN,
or GetAndSetN. If the safepoint is a call, then it needs to be a platform that has
"never-save" (NS) registers that can stay live across a call. But if the safepoint is a poll,
then probably any platform would be affected.
block as their use, and in PhaseCFG::select() there is more code to keep MachTemp
nodes near their use. However, the MachTemp can still end up in a different block
from it use (call_catch_cleanup() is one function that can cause this.)
Since a MachTemp node doesn't actually emit any code, the register allocation for
it hasn't actually been initialized until the use node. Normally this is harmless,
but if the MachTemp is RegN, then any safepoint between the MachTemp and use
will add that RegN to the safepoint oopmap, which is fatal because the value is
uninitialized. Even if the MachTemp is not a RegN, having the MachTemp far away
from its use unnecessarily extends the live range of the register.
A possible fix for the general case would be to make sure that MachTemp
nodes are always placed just above their use in the same block.
A workaround for just the RegN case could be to treat RegN as RegI for MachTemp nodes.
To reproduce this problem, add a RegN TEMP to a rule like LoadN, CompareAndSwapN,
or GetAndSetN. If the safepoint is a call, then it needs to be a platform that has
"never-save" (NS) registers that can stay live across a call. But if the safepoint is a poll,
then probably any platform would be affected.
- relates to
-
JDK-8265784 [C2] Hoisting of DecodeN leaves MachTemp inputs behind
- Resolved