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

[Eli Friedman]

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.

> 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.)

> 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.

-Eli