diff options
| author | Mark Lacey <mark.lacey@apple.com> | 2019-02-13 22:56:43 +0000 |
|---|---|---|
| committer | Mark Lacey <mark.lacey@apple.com> | 2019-02-13 22:56:43 +0000 |
| commit | c18b8a8bc5fd3a7a2ac989bca4494ee3be289170 (patch) | |
| tree | a97d26ac15915f6ddc4246b504075c9414351221 /llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp | |
| parent | 8a56d10a2ff0f14709362aecde0c9ac0a7335c24 (diff) | |
| download | llvm-c18b8a8bc5fd3a7a2ac989bca4494ee3be289170.zip llvm-c18b8a8bc5fd3a7a2ac989bca4494ee3be289170.tar.gz llvm-c18b8a8bc5fd3a7a2ac989bca4494ee3be289170.tar.bz2 | |
[RegAllocGreedy] Take last chance recoloring into account in evicting.
Last chance recoloring inserts into FixedRegisters those virtual
registers it is attempting to assign a physical register to.
We must consider these when we consider candidates for eviction so that
we do not end up evicting something while we are attempting to recolor
to assign it.
This is hitting in an out-of-tree target and no longer reproduces on
trunk. That does not appear to be a result of it having been fixed, but
rather, it appears that optimization changes and/or other changes to
register allocation mask the problem.
I haven't found a way to come up with a reasonable test case for this
(i.e. one that I can actually commit to open source, is reasonable
in size, and actually reproduces the issue).
rdar://problem/45708741
llvm-svn: 353988
Diffstat (limited to 'llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp')
0 files changed, 0 insertions, 0 deletions