diff options
| author | Wei Mi <wmi@google.com> | 2016-11-08 18:19:36 +0000 |
|---|---|---|
| committer | Wei Mi <wmi@google.com> | 2016-11-08 18:19:36 +0000 |
| commit | b5cf9e53e5d897c63680bc0a1ff4234670983e0b (patch) | |
| tree | 59d03d39d12eb83e9821028460fb3101ae25f15d /lldb/packages/Python/lldbsuite/test/expression_command/timeout/wait-a-while.cpp | |
| parent | b6f833793d03a35faa1523ebadf454ea6efad159 (diff) | |
| download | bcm5719-llvm-b5cf9e53e5d897c63680bc0a1ff4234670983e0b.tar.gz bcm5719-llvm-b5cf9e53e5d897c63680bc0a1ff4234670983e0b.zip | |
[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
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/timeout/wait-a-while.cpp')
0 files changed, 0 insertions, 0 deletions
