llvm dev - Mar 2010 - [LLVMdev] LLVM tries to remove labels used in blockaddress()

I see. But the block does not necessarily contain dead code.

My original problem is more like this:

define i32 @main() {
entry:
	%target = bitcast i8* blockaddress(@test_fun, %test_label) to i8*

	call i32 @test_fun(i8* %target)

	ret i32 0
}

define i32 @test_fun(i8* %target) {
entry:
	indirectbr i8* %target, [label %test_label]

test_label:
; assume some code here...
	br label %ret

ret:
	ret i32 -1
}

The code after test_label can be reached, but this example produces also an
error.

Regards,
Sebastian

On Monday 15 March 2010 17:41:18 you wrote:
> 
> On Mar 15, 2010, at 7:11 AM, Sebastian Schlunke wrote:
> 
> > Hi,
> > 
> > i ran into a problem when using blockaddress() with a label in another
function. It seems to me that LLVM tries to remove the label used in
blockaddress because it seems like it is not used, but in fact it may be used
somewhere with a indirectbr.
> > 
> > I attached a small test-case that produces this error. (The original
problem is much more complicated, so i hope the reduced example, which has no
indirectbr but produces an error nevertheless, will suffice.)
> 
> This is because of new checking code I added, specifically to catch bugs
like:
> 
> > An earlier revision simply generated asm-code, where the appropriate
label was missing, thus causing gcc to fail when i wanted to compile the
asm-file.
> 
> Here is a slightly reduced testcase:
> 
> define i8* @test1() nounwind {
> entry:
> 	ret i8* blockaddress(@test_fun, %test_label)
> }
> 
> define i32 @test_fun() nounwind {
> entry:
> 	ret i32 -1
> test_label:
> 	br label %ret
> ret:
> 	ret i32 -1
> }
> 
> The basic problem is that we codegen test1, which generates a reference to
test_label, then we codegen test_func.  The optimization passes that run before
the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead blocks,
so test_label was being deleted.
> 
> The code generator doesn't want dead blocks coming into it for various
reasons, so removing them is important.  I guess we'll have to do something
like buffer up the unemitted labels and emit them at the end of the file (in a
meaningless location).  This should provide correct code, but is somewhat gross.
> 
> Bob/Dan, do you guys have any other ideas on how to handle this?
> 
> -Chris
>

This is a related, but different (and more important!) issue.  I think I have a
solution for both problems, thanks for pointing this out.

-Chris

On Mar 15, 2010, at 10:01 AM, Sebastian Schlunke wrote:
> I see. But the block does not necessarily contain dead code.
> 
> My original problem is more like this:
> 
> define i32 @main() {
> entry:
> 	%target = bitcast i8* blockaddress(@test_fun, %test_label) to i8*
> 
> 	call i32 @test_fun(i8* %target)
> 
> 	ret i32 0
> }
> 
> define i32 @test_fun(i8* %target) {
> entry:
> 	indirectbr i8* %target, [label %test_label]
> 
> test_label:
> ; assume some code here...
> 	br label %ret
> 
> ret:
> 	ret i32 -1
> }
> 
> The code after test_label can be reached, but this example produces also an
error.
> 
> Regards,
> Sebastian
> 
> On Monday 15 March 2010 17:41:18 you wrote:
>> 
>> On Mar 15, 2010, at 7:11 AM, Sebastian Schlunke wrote:
>> 
>>> Hi,
>>> 
>>> i ran into a problem when using blockaddress() with a label in
another function. It seems to me that LLVM tries to remove the label used in
blockaddress because it seems like it is not used, but in fact it may be used
somewhere with a indirectbr.
>>> 
>>> I attached a small test-case that produces this error. (The
original problem is much more complicated, so i hope the reduced example, which
has no indirectbr but produces an error nevertheless, will suffice.)
>> 
>> This is because of new checking code I added, specifically to catch
bugs like:
>> 
>>> An earlier revision simply generated asm-code, where the
appropriate label was missing, thus causing gcc to fail when i wanted to compile
the asm-file.
>> 
>> Here is a slightly reduced testcase:
>> 
>> define i8* @test1() nounwind {
>> entry:
>> 	ret i8* blockaddress(@test_fun, %test_label)
>> }
>> 
>> define i32 @test_fun() nounwind {
>> entry:
>> 	ret i32 -1
>> test_label:
>> 	br label %ret
>> ret:
>> 	ret i32 -1
>> }
>> 
>> The basic problem is that we codegen test1, which generates a reference
to test_label, then we codegen test_func.  The optimization passes that run
before the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead
blocks, so test_label was being deleted.
>> 
>> The code generator doesn't want dead blocks coming into it for
various reasons, so removing them is important.  I guess we'll have to do
something like buffer up the unemitted labels and emit them at the end of the
file (in a meaningless location).  This should provide correct code, but is
somewhat gross.
>> 
>> Bob/Dan, do you guys have any other ideas on how to handle this?
>> 
>> -Chris
>>

On Mar 15, 2010, at 10:01 AM, Sebastian Schlunke wrote:
> I see. But the block does not necessarily contain dead code.
This case is now fixed in r98566, I will fix the 'dead block' case in a
bit.

-Chris
> 
> My original problem is more like this:
> 
> define i32 @main() {
> entry:
> 	%target = bitcast i8* blockaddress(@test_fun, %test_label) to i8*
> 
> 	call i32 @test_fun(i8* %target)
> 
> 	ret i32 0
> }
> 
> define i32 @test_fun(i8* %target) {
> entry:
> 	indirectbr i8* %target, [label %test_label]
> 
> test_label:
> ; assume some code here...
> 	br label %ret
> 
> ret:
> 	ret i32 -1
> }
> 
> The code after test_label can be reached, but this example produces also an
error.
> 
> Regards,
> Sebastian
> 
> On Monday 15 March 2010 17:41:18 you wrote:
>> 
>> On Mar 15, 2010, at 7:11 AM, Sebastian Schlunke wrote:
>> 
>>> Hi,
>>> 
>>> i ran into a problem when using blockaddress() with a label in
another function. It seems to me that LLVM tries to remove the label used in
blockaddress because it seems like it is not used, but in fact it may be used
somewhere with a indirectbr.
>>> 
>>> I attached a small test-case that produces this error. (The
original problem is much more complicated, so i hope the reduced example, which
has no indirectbr but produces an error nevertheless, will suffice.)
>> 
>> This is because of new checking code I added, specifically to catch
bugs like:
>> 
>>> An earlier revision simply generated asm-code, where the
appropriate label was missing, thus causing gcc to fail when i wanted to compile
the asm-file.
>> 
>> Here is a slightly reduced testcase:
>> 
>> define i8* @test1() nounwind {
>> entry:
>> 	ret i8* blockaddress(@test_fun, %test_label)
>> }
>> 
>> define i32 @test_fun() nounwind {
>> entry:
>> 	ret i32 -1
>> test_label:
>> 	br label %ret
>> ret:
>> 	ret i32 -1
>> }
>> 
>> The basic problem is that we codegen test1, which generates a reference
to test_label, then we codegen test_func.  The optimization passes that run
before the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead
blocks, so test_label was being deleted.
>> 
>> The code generator doesn't want dead blocks coming into it for
various reasons, so removing them is important.  I guess we'll have to do
something like buffer up the unemitted labels and emit them at the end of the
file (in a meaningless location).  This should provide correct code, but is
somewhat gross.
>> 
>> Bob/Dan, do you guys have any other ideas on how to handle this?
>> 
>> -Chris
>>

Works like a charm! Thanks for the fast help. :)

- Sebastian

On Monday 15 March 2010 20:10:54 you wrote:
> 
> On Mar 15, 2010, at 10:01 AM, Sebastian Schlunke wrote:
> 
> > I see. But the block does not necessarily contain dead code.
> 
> This case is now fixed in r98566, I will fix the 'dead block' case
in a bit.
> 
> -Chris
> 
> > 
> > My original problem is more like this:
> > 
> > define i32 @main() {
> > entry:
> > 	%target = bitcast i8* blockaddress(@test_fun, %test_label) to i8*
> > 
> > 	call i32 @test_fun(i8* %target)
> > 
> > 	ret i32 0
> > }
> > 
> > define i32 @test_fun(i8* %target) {
> > entry:
> > 	indirectbr i8* %target, [label %test_label]
> > 
> > test_label:
> > ; assume some code here...
> > 	br label %ret
> > 
> > ret:
> > 	ret i32 -1
> > }
> > 
> > The code after test_label can be reached, but this example produces
also an error.
> > 
> > Regards,
> > Sebastian
> > 
> > On Monday 15 March 2010 17:41:18 you wrote:
> >> 
> >> On Mar 15, 2010, at 7:11 AM, Sebastian Schlunke wrote:
> >> 
> >>> Hi,
> >>> 
> >>> i ran into a problem when using blockaddress() with a label in
another function. It seems to me that LLVM tries to remove the label used in
blockaddress because it seems like it is not used, but in fact it may be used
somewhere with a indirectbr.
> >>> 
> >>> I attached a small test-case that produces this error. (The
original problem is much more complicated, so i hope the reduced example, which
has no indirectbr but produces an error nevertheless, will suffice.)
> >> 
> >> This is because of new checking code I added, specifically to
catch bugs like:
> >> 
> >>> An earlier revision simply generated asm-code, where the
appropriate label was missing, thus causing gcc to fail when i wanted to compile
the asm-file.
> >> 
> >> Here is a slightly reduced testcase:
> >> 
> >> define i8* @test1() nounwind {
> >> entry:
> >> 	ret i8* blockaddress(@test_fun, %test_label)
> >> }
> >> 
> >> define i32 @test_fun() nounwind {
> >> entry:
> >> 	ret i32 -1
> >> test_label:
> >> 	br label %ret
> >> ret:
> >> 	ret i32 -1
> >> }
> >> 
> >> The basic problem is that we codegen test1, which generates a
reference to test_label, then we codegen test_func.  The optimization passes
that run before the code generator (UnreachableBlockElim & CodeGenPrepare)
zap dead blocks, so test_label was being deleted.
> >> 
> >> The code generator doesn't want dead blocks coming into it for
various reasons, so removing them is important.  I guess we'll have to do
something like buffer up the unemitted labels and emit them at the end of the
file (in a meaningless location).  This should provide correct code, but is
somewhat gross.
> >> 
> >> Bob/Dan, do you guys have any other ideas on how to handle this?
> >> 
> >> -Chris