Preserve 2-addr constraints in ConnectedVNInfoEqClasses.

When a live range splits into multiple connected components, we would
arbitrarily assign <undef> uses to component 0. This is wrong when the
use is tied to a def that gets assigned to a different component:

  %vreg69<def> = ADD8ri %vreg68<undef>, 1

The use and def must get the same virtual register.

Fix this by assigning <undef> uses to the same component as the value
defined by the instruction, if any:

  %vreg69<def> = ADD8ri %vreg69<undef>, 1

This fixes PR13402. The PR has a test case which I am not including
because it is unlikely to keep exposing this behavior in the future.

llvm-svn: 160739
This commit is contained in:
Jakob Stoklund Olesen 2012-07-25 17:15:15 +00:00
parent 6b375193a2
commit cef9a618b1
1 changed files with 4 additions and 7 deletions

View File

@ -827,14 +827,11 @@ void ConnectedVNInfoEqClasses::Distribute(LiveInterval *LIV[],
MachineOperand &MO = RI.getOperand();
MachineInstr *MI = MO.getParent();
++RI;
if (MO.isUse() && MO.isUndef())
continue;
// DBG_VALUE instructions should have been eliminated earlier.
SlotIndex Idx = LIS.getInstructionIndex(MI);
Idx = Idx.getRegSlot(MO.isUse());
const VNInfo *VNI = LI.getVNInfoAt(Idx);
// FIXME: We should be able to assert(VNI) here, but the coalescer leaves
// dangling defs around.
LiveRangeQuery LRQ(LI, LIS.getInstructionIndex(MI));
const VNInfo *VNI = MO.readsReg() ? LRQ.valueIn() : LRQ.valueDefined();
// In the case of an <undef> use that isn't tied to any def, VNI will be
// NULL. If the use is tied to a def, VNI will be the defined value.
if (!VNI)
continue;
MO.setReg(LIV[getEqClass(VNI)]->reg);