aboutsummaryrefslogtreecommitdiffstats
path: root/ModuleInfo.txt
diff options
context:
space:
mode:
authorAndrew Trick <atrick@apple.com>2011-01-27 21:26:43 +0000
committerAndrew Trick <atrick@apple.com>2011-01-27 21:26:43 +0000
commit5d7ab8503b130f142902a043556b6b1febd33744 (patch)
tree40b847c23fc6cac31e8b30d6fa8d84a68cd341bb /ModuleInfo.txt
parent75f6e89ea9f8fe9cf8c8f9fe6a3322bd6566fdf1 (diff)
downloadexternal_llvm-5d7ab8503b130f142902a043556b6b1febd33744.zip
external_llvm-5d7ab8503b130f142902a043556b6b1febd33744.tar.gz
external_llvm-5d7ab8503b130f142902a043556b6b1febd33744.tar.bz2
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124442 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'ModuleInfo.txt')
0 files changed, 0 insertions, 0 deletions