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

On Mar 15, 2010, at 9:41 AM, Chris Lattner 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.
I'm not sure I understand completely.  We should be able to rely on the
indirectbr label arguments to identify blocks that are live.  You can have a
blockaddress anywhere, but indirectbr is only defined within a function so
there's no ordering problem if you're looking at the indirectbr.
> 
> 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?
Is the problem when you've got a blockaddress that references a dead label
in a different function?  If that's the case, the blockaddress value can be
an undef.

On Mar 15, 2010, at 10:07 AM, Bob Wilson wrote:
>>> 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.
> 
> I'm not sure I understand completely.  We should be able to rely on the
indirectbr label arguments to identify blocks that are live.  You can have a
blockaddress anywhere, but indirectbr is only defined within a function so
there's no ordering problem if you're looking at the indirectbr.
The problem is that test1 is codegen'd and the reference to test_label is
emitted to the .s file.  By the time test_func is codegen'd, the block is
deleted, so the definition isn't emitted.  I'll fix this.
>> 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?
> 
> Is the problem when you've got a blockaddress that references a dead
label in a different function?  If that's the case, the blockaddress value
can be an undef.
But the reference has already been emitted to the .s file.  I'll take care
of this by just queuing up labels and emitting them at the end of the function
they correspond to.

-Chris

On Mar 15, 2010, at 11:18 AM, Chris Lattner wrote:
> 
> The problem is that test1 is codegen'd and the reference to test_label
is emitted to the .s file.  By the time test_func is codegen'd, the block is
deleted, so the definition isn't emitted.  I'll fix this.
> 
>>> 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?
>> 
>> Is the problem when you've got a blockaddress that references a
dead label in a different function?  If that's the case, the blockaddress
value can be an undef.
> 
> But the reference has already been emitted to the .s file.  I'll take
care of this by just queuing up labels and emitting them at the end of the
function they correspond to.
Oh, I get it.  Yuck.  I can't think of any better solutions ATM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100315/7f698e51/attachment.html>