[LLVMdev] 'Address of Label and Indirect Branches in LLVM IR' blog post

[Török Edwin]

On 2010-01-03 13:33, Eli Friedman wrote:
> 2010/1/3 Török Edwin <edwintorok at gmail.com>:
>   
>> On 2010-01-03 10:33, Chris Lattner wrote:
>>     
>>> If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design:
>>> http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html
>>>
>>> This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November.  If you have questions or comments about the post, this is a good thread to discuss them on :)
>>>
>>>       
>> Can a label be listed multiple times in indirectbr?
>>     
>
> Yes; it's not particularly meaningful, but it's not difficult to
> construct a case where the optimizer will introduce such a construct.
>   

Ok.

>   
>> Clang generates this:
>> foo:                                              ; preds =
>> %indirectgoto, %indirectgoto, %indirectgoto, %indirectgoto, %indirectgoto
>>  store i32 1, i32* %retval
>>  br label %return
>>
>> indirectbr i8* %indirect.goto.dest, [label %foo, label %foo, label %bar,
>> label %foo, label %hack, label %foo, label %foo]
>>
>> For this code taken from the gcc manual:
>> ....
>>     static const int array[] = { &&foo - &&foo, &&bar - &&foo,
>>                                  &&hack - &&foo };
>>     goto *(&&foo + array[i]);
>> .....
>>
>> If I remove &&foo - &&foo from the array, clang still thinks that &&foo
>> is a possible destination, even if I run some optimizers on it.
>> Since the argument to goto is an array of constants, it should be
>> possible for an optimizer to determine the exact list of destinations.
>>     
>
> Missed optimization, I guess... put it into lib/Target/README.txt if
> you think it's an interesting case to try to optimize.  (It doesn't
> strike me as particularly interesting because anyone using indirect
> gotos is going to coding carefully anyway.)
>   

If the code generator isn't confused by the multiple destinations then
its fine.
I can't think of a situation where the presence or the lack of that one
extra edge would matter.

>   
>> Also the intent of that code is to allow it to go into a readonly
>> section, however with Clang it only goes to a .data.rel.ro section (with
>> -fPIC):
>>     
>
> Another missed optimization; this one seems pretty important, though.
>   


On 2010-01-03 13:14, Anton Korobeynikov wrote:
> Hello, Edwin
>
>   
>> Also the intent of that code is to allow it to go into a readonly
>> section, however with Clang it only goes to a .data.rel.ro section (with
>> -fPIC):
>>     
> Sounds like a bug. Fill a PR and assign to me. I will look into it
> when I return from vacations.
>
>   

Done, PR5929.

Best regards,
--Edwin