diff options
| author | Andrew Trick <atrick@apple.com> | 2011-01-27 21:26:43 +0000 |
|---|---|---|
| committer | Andrew Trick <atrick@apple.com> | 2011-01-27 21:26:43 +0000 |
| commit | 13bb644fddf3d1fa5b57315c704f91eab465aa4a (patch) | |
| tree | 22ce6bd868d1ba0862a849eb38a1f31e577f094c /clang/lib/Sema/Sema.cpp | |
| parent | 61b7f5e3fd999819c1e375d98c198e8cdd1c49c3 (diff) | |
| download | bcm5719-llvm-13bb644fddf3d1fa5b57315c704f91eab465aa4a.tar.gz bcm5719-llvm-13bb644fddf3d1fa5b57315c704f91eab465aa4a.zip | |
VirtRegRewriter fix: update kill flags, which are used by the scavenger.
rdar://problem/8893967: JM/lencod miscompile at -arch armv7 -mthumb -O3
Added ResurrectKill to remove kill flags after we decide to reused a
physical register. And (hopefully) ensure that we call it in all the
right places.
Sorry, I'm not checking in a unit test given that it's a miscompile I
can't reproduce easily with a toy example. Failures in the rewriter
depend on a series of heuristic decisions maked during one of the many
upstream phases in codegen. This case would require coercing regalloc
to generate a couple of rematerialzations in a way that causes the
scavenger to reuse the same register at just the wrong point.
The general way to test this is to implement kill flags
verification. Then we could have a simple, robust compile-only unit
test. That would be worth doing if the whole pass was not about to
disappear. At this point we focus verification work on the next
generation of regalloc.
llvm-svn: 124442
Diffstat (limited to 'clang/lib/Sema/Sema.cpp')
0 files changed, 0 insertions, 0 deletions
