diff options
| author | Bob Wilson <bob.wilson@apple.com> | 2009-09-05 01:19:16 +0000 |
|---|---|---|
| committer | Bob Wilson <bob.wilson@apple.com> | 2009-09-05 01:19:16 +0000 |
| commit | da4ae4be5b2b8fa35ef989e548530833428f36bf (patch) | |
| tree | c52591d2d1555f1ff541da9ca54accc9a68118ad /test/CodeGen/X86/stack-color-with-reg.ll | |
| parent | bd1d6a8ce1197de640df52e1da2e63e8ce8d8705 (diff) | |
| download | external_llvm-da4ae4be5b2b8fa35ef989e548530833428f36bf.zip external_llvm-da4ae4be5b2b8fa35ef989e548530833428f36bf.tar.gz external_llvm-da4ae4be5b2b8fa35ef989e548530833428f36bf.tar.bz2 | |
Stabilize the order of live intervals in the priority_queue used by the
linear scan reg alloc. This fixes a problem I ran into where extracting
a function from a larger file caused the generated code to change (masking
the problem I was trying to debug) because the allocator behaved differently.
This changes the results for two X86 regression checks. stack-color-with-reg
is improved, with one less instruction, but pr3495 is worse, with one more
copy. As far as I can tell, these tests were just getting lucky or unlucky,
so I've changed the expected results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81060 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/CodeGen/X86/stack-color-with-reg.ll')
| -rw-r--r-- | test/CodeGen/X86/stack-color-with-reg.ll | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/test/CodeGen/X86/stack-color-with-reg.ll b/test/CodeGen/X86/stack-color-with-reg.ll index 114e9bf..604bd4f 100644 --- a/test/CodeGen/X86/stack-color-with-reg.ll +++ b/test/CodeGen/X86/stack-color-with-reg.ll @@ -1,7 +1,7 @@ ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin10 -relocation-model=pic -disable-fp-elim -color-ss-with-regs -stats -info-output-file - > %t ; RUN: grep stackcoloring %t | grep "loads eliminated" ; RUN: grep stackcoloring %t | grep "stack slot refs replaced with reg refs" | grep 5 -; RUN: grep asm-printer %t | grep 182 +; RUN: grep asm-printer %t | grep 181 type { [62 x %struct.Bitvec*] } ; type %0 type { i8* } ; type %1 |