Fix the third (and last known) case of code update problems due

to LLVM IR changes with addr label weirdness.  In the testcase, we
generate references to the two bb's when codegen'ing the first
function:

_test1:                                 ## @test1
	leaq	Ltmp0(%rip), %rax
..
	leaq	Ltmp1(%rip), %rax

Then continue to codegen the second function where the blocks
get merged.  We're now smart enough to emit both labels, producing
this code:

_test_fun:                              ## @test_fun
## BB#0:                                ## %entry
Ltmp1:                                  ## Block address taken
Ltmp0:
## BB#1:                                ## %ret
	movl	$-1, %eax
	ret

Rejoice.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98595 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner
2010-03-16 00:29:39 +00:00
parent 4e815f8a8c
commit 999aee24c7
4 changed files with 146 additions and 28 deletions

View File

@@ -215,6 +215,11 @@ public:
/// because the block may be accessed outside its containing function.
MCSymbol *getAddrLabelSymbol(const BasicBlock *BB);
/// getAddrLabelSymbolToEmit - Return the symbol to be used for the specified
/// basic block when its address is taken. If other blocks were RAUW'd to
/// this one, we may have to emit them as well, return the whole set.
std::vector<MCSymbol*> getAddrLabelSymbolToEmit(const BasicBlock *BB);
/// takeDeletedSymbolsForFunction - If the specified function has had any
/// references to address-taken blocks generated, but the block got deleted,
/// return the symbol now so we can emit it. This prevents emitting a