llvm dev - Sep 2012 - [LLVMdev] Label address (taken with blockaddress) not exported to .s

Hi all,

I recently updated my LLVM tree and I have a strange issue with the use
of blockaddress. The LLVM file that I try to compile is [1].

I do:
> llvm-as test_ba.ll
> opt -O2 test_ba.bc -o test_ba_opt.bc
> llc test_ba_opt.bc
In r159116 (committed in 24/06/2012) I get (in the end of the .s file):

	.type	table_closures, at object  # @table_closures
	.section	.rodata,"a", at progbits
	.globl	table_closures
	.align	8
table_closures:
	.quad	.Ltmp0
	.quad	.Ltmp1
	.size	table_closures, 16


While in r164026 (committed in 17/09/2012) I get:

	.type	table_closures, at object  # @table_closures
	.section	.rodata,"a", at progbits
	.globl	table_closures
	.align	8
table_closures:
	.quad	.Ltmp0
	.quad	1
	.size	table_closures, 16

i.e. One label address is not properly exported in the table.

Is there something wrong here? Or am I missing something?


Best regards,
Yiannis

PS: Sorry for the poor testcase but I couldn't reduce it anymore. I'll
try harder and post again if that's needed.

[1]: https://gist.github.com/3738404

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour

On 9/17/2012 11:59 AM, Yiannis Tsiouris wrote:
> Hi all,
>
> I recently updated my LLVM tree and I have a strange issue with the use
> of blockaddress. The LLVM file that I try to compile is [1].
Taking the address of a block by itself has zero guarantees about 
whether or not that block will exist by the time the code is emitted. If 
the block no longer exists by the end, it gets replaced with a constant 1.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

On Mon, Sep 17, 2012 at 12:06 PM, Joshua Cranmer <pidgeot18 at gmail.com>
wrote:
> On 9/17/2012 11:59 AM, Yiannis Tsiouris wrote:
>>
>> Hi all,
>>
>> I recently updated my LLVM tree and I have a strange issue with the use
>> of blockaddress. The LLVM file that I try to compile is [1].
>
>
> Taking the address of a block by itself has zero guarantees about whether
or
> not that block will exist by the time the code is emitted. If the block no
> longer exists by the end, it gets replaced with a constant 1.
>
To add on to this, take a look at the LLVM blog post on this,
particularly the end:
http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html
.

In short, BlockAddress values that aren't used in an indirectbr are
not something LLVM will make any effort to preserve for you.

When the underlying block is merged/removed/etc what Joshua said above
comes into play: the address is replaced with a constant 1. Check the
BasicBlock destructor for the source of this behavior.

Hope this helps,

~Will