[LiveRangeEdit] Fix a crash in eliminateDeadDef.

When we delete a live-range, we check if that live-range is the origin of others
to keep it around for rematerialization. For that we check that the instruction
we are about to remove is the same as the definition of the VNI of the original
live-range.
If this is the case, we just shrink the live-range to an empty one.

Now, when we try to delete one of the children of such live-range (product of
splitting), we do the same check.
However, now the original live-range is empty and there is no way we can
access the VNI to check its definition, and we crash.

When we cannot get the VNI for the original live-range, that means we are not in
the presence of the original definition. Thus, this check does not need to happen
in that case and the crash is sloved!

This bug was introduced in r266162 | wmi | 2016-04-12 20:08:27. It affects every
target that uses the greedy register allocator.
To happen, we need to delete both a the original instruction and its split
products, in that order. This is likely to happen when rematerialization comes
into play.

Trying to produce a more robust test case. Will follow in a coming commit.

This fixes llvm.org/PR27983.

rdar://problem/26651519 

llvm-svn: 272314
This commit is contained in:
Quentin Colombet 2016-06-09 21:34:31 +00:00
parent bae0eeaf2e
commit d307909a50
1 changed files with 6 additions and 1 deletions

View File

@ -267,7 +267,12 @@ void LiveRangeEdit::eliminateDeadDef(MachineInstr *MI, ToShrinkSet &ToShrink) {
unsigned Original = VRM->getOriginal(Dest);
LiveInterval &OrigLI = LIS.getInterval(Original);
VNInfo *OrigVNI = OrigLI.getVNInfoAt(Idx);
isOrigDef = SlotIndex::isSameInstr(OrigVNI->def, Idx);
// The original live-range may have been shrunk to
// an empty live-range. It happens when it is dead, but
// we still keep it around to be able to rematerialize
// other values that depend on it.
if (OrigVNI)
isOrigDef = SlotIndex::isSameInstr(OrigVNI->def, Idx);
}
// Check for live intervals that may shrink