r218141 - In the Itanium ABI, move stuff to the comdat of variables with static init.

[Richard Smith]

On Wed, Dec 17, 2014 at 1:32 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Wed, Dec 17, 2014 at 12:48 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> Are we sure this is correct? In the motivating example, what if 'f' gets
>> inlined? Then 'g' will have the code of 'f' embedded into it, but it will
>> not be part of the comdat that statically initializes the guard variable.
>>
>> struct S {
>>   static const int x;
>> };
>> // const int S::x = 42;
>> inline const int *f() {
>>   static const int y = S::x;
>>   return &y;
>> }
>> const int *g() { return f(); }
>>
>> I spent a coffee break a few weeks ago worrying about this, and we came
>> to the conclusion that we can't do this if we want to support inlining from
>> a comdat. Maybe it's illegal for LLVM to inline f from a comdat, but that's
>> pretty sad.
>>
>
> It is. Do we have any alternative that supports inlining and the above
> testcase?
>

(Summarizing offline discussion)

While evaluating the initializer for a static local variable, we can track
whether the initialization depends on any properties that might not hold in
another translation unit. If it does, then we should assume that the
variable may have dynamic initialization in another TU. In that case:

 - generate a guard variable that is initialized to the "already
initialized" state.
 - generate code to initialize the variable within the local function (just
copy across the constant value).

This removes any need to put the inline function into a COMDAT with the
static local variable. (We still need to put the local variable and its
guard variable in a COMDAT together, though.)


Separately, it seems that LLVM should not inline across COMDAT boundaries,
unless it somehow knows that every definition of the COMDAT will provide an
equivalent definition of the symbol (for instance, because it's got an
*_odr linkage), and likewise for other optimizations that transfer
information between globals. A strong definition in a COMDAT should behave
similarly to a weak definition.

On Tue, Dec 16, 2014 at 1:02 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> On 1 November 2014 at 14:29, Richard Smith <richard at metafoo.co.uk>
>>> wrote:
>>> > Thanks, that sounds ideal.
>>>
>>> Finally fixed by r224369. Sorry for the delay.
>>>
>>> Cheers,
>>> Rafael
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141217/771da849/attachment.html>