[RegAllocGreedy] Another fix about NewVRegs for last chance recoloring after r281783.
authorWei Mi <wmi@google.com>
Tue, 8 Nov 2016 18:19:36 +0000 (18:19 +0000)
committerWei Mi <wmi@google.com>
Tue, 8 Nov 2016 18:19:36 +0000 (18:19 +0000)
commitb5cf9e53e5d897c63680bc0a1ff4234670983e0b
tree59d03d39d12eb83e9821028460fb3101ae25f15d
parentb6f833793d03a35faa1523ebadf454ea6efad159
[RegAllocGreedy] Another fix about NewVRegs for last chance recoloring after r281783.

About when we should move a vreg from CurrentNewVRegs to NewVRegs,
if the vreg in CurrentNewVRegs was added into RecoloringCandidate and was
evicted, it shouldn't be added to NewVRegs because its physical register
will be restored at the end of tryLastChanceRecoloring after the recoloring
failed. If the vreg in CurrentNewVRegs was not in RecoloringCandidate, i.e.
it was evicted in selectOrSplitImpl inside tryRecoloringCandidates, its
physical register will not be restored even if the recoloring failed. In
that case, we need to add the vreg to NewVRegs.

Same as r281783, the problem was seen on out-of-tree target and we didn't
have a test case that reproduce the problem with in-tree targets.

llvm-svn: 286259
llvm/lib/CodeGen/RegAllocGreedy.cpp