llvm-6502/test/CodeGen/Generic/addr-label.ll
Chris Lattner 999aee24c7 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
2010-03-16 00:29:39 +00:00

59 lines
1.0 KiB
LLVM

; RUN: llc %s -o -
;; Reference to a label that gets deleted.
define i8* @test1() nounwind {
entry:
ret i8* blockaddress(@test1b, %test_label)
}
define i32 @test1b() nounwind {
entry:
ret i32 -1
test_label:
br label %ret
ret:
ret i32 -1
}
;; Issues with referring to a label that gets RAUW'd later.
define i32 @test2a() nounwind {
entry:
%target = bitcast i8* blockaddress(@test2b, %test_label) to i8*
call i32 @test2b(i8* %target)
ret i32 0
}
define i32 @test2b(i8* %target) nounwind {
entry:
indirectbr i8* %target, [label %test_label]
test_label:
; assume some code here...
br label %ret
ret:
ret i32 -1
}
; Issues with a BB that gets RAUW'd to another one after references are
; generated.
define void @test3(i8** %P, i8** %Q) nounwind {
entry:
store i8* blockaddress(@test3b, %test_label), i8** %P
store i8* blockaddress(@test3b, %ret), i8** %Q
ret void
}
define i32 @test3b() nounwind {
entry:
br label %test_label
test_label:
br label %ret
ret:
ret i32 -1
}