llvm dev - Sep 2013 - [LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors

To implement
http://llvm.org/PR16959<http://llvm.org/bugs/show_bug.cgi?id=16959>,
I need to add a new field to global_ctors.

Static data members of class template instantiations can have initializers
that must only run once on program startup.  Itanium solves this with guard
variables and the emission of multiple initializers, only one of which
actually initializes the data at runtime.

Microsoft solves this by using a COFF comdat feature called
IMAGE_COMDAT_SELECT_ASSOCIATIVE.
The semantics are that the section with this attribute is only linked if
the associated section is chosen for the final link. Otherwise it is
discarded.

In this way, only one initializer is linked and only one entry is produced
in the initializer array (.CRT$XCU). Everyone I've spoken with so far
thinks this is basically awesome and is much cleaner than using guard
variables. :)

I propose changing LangRef to make llvm.global_ctors and llvm.global_dtors
be arrays of { i32, void()*, i8* }, where the last field is an optional
pointer to a GlobalValue. Old modules containing { i32, void()*} elements
will also be accepted, and the missing third field will be assumed to be
null.

When performing LTO, if there are multiple entries with the same associated
global, only one of them will be kept in the linked module. Similarly, on
targets supporting this feature (COFF for the moment, but maybe ELF one day
as an optimization), LLVM will emit the appropriate comdat bits so that the
system linker behaves similarly. On platforms lacking this support, the old
behavior will be used, in which case guard variables are still necessary.

This seems fairly uncontroversial, but let me know if anyone objects. I'll
try to send patches later this week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130826/30ed914b/attachment.html>

Hi Reid,

On 26/08/13 23:43, Reid Kleckner wrote:
> To implement http://llvm.org/PR16959
> <http://llvm.org/bugs/show_bug.cgi?id=16959>, I need to add a new
field to
> global_ctors.
>
> Static data members of class template instantiations can have initializers
that
> must only run once on program startup.  Itanium solves this with guard
variables
> and the emission of multiple initializers, only one of which actually
> initializes the data at runtime.
>
> Microsoft solves this by using a COFF comdat feature called
> IMAGE_COMDAT_SELECT_ASSOCIATIVE. The semantics are that the section with
this
> attribute is only linked if the associated section is chosen for the final
link.
> Otherwise it is discarded.
>
> In this way, only one initializer is linked and only one entry is produced
in
> the initializer array (.CRT$XCU). Everyone I've spoken with so far
thinks this
> is basically awesome and is much cleaner than using guard variables. :)
>
> I propose changing LangRef to make llvm.global_ctors and llvm.global_dtors
be
> arrays of { i32, void()*, i8* }, where the last field is an optional
pointer to
> a GlobalValue. Old modules containing { i32, void()*} elements will also be
> accepted, and the missing third field will be assumed to be null.
>
> When performing LTO, if there are multiple entries with the same associated
> global, only one of them will be kept in the linked module.
will two different globals have different initialization functions too, or will
the same function be reused for many different globals?

Thanks, Duncan.

  Similarly, on
> targets supporting this feature (COFF for the moment, but maybe ELF one day
as
> an optimization), LLVM will emit the appropriate comdat bits so that the
system
> linker behaves similarly. On platforms lacking this support, the old
behavior
> will be used, in which case guard variables are still necessary.
>
> This seems fairly uncontroversial, but let me know if anyone objects.
I'll try
> to send patches later this week.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Mon, Sep 2, 2013 at 5:18 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Reid,
>
> On 26/08/13 23:43, Reid Kleckner wrote:
>
>> To implement http://llvm.org/PR16959
>>
<http://llvm.org/bugs/show_**bug.cgi?id=16959<http://llvm.org/bugs/show_bug.cgi?id=16959>>,
>> I need to add a new field to
>>
>> global_ctors.
>>
>> Static data members of class template instantiations can have
>> initializers that
>> must only run once on program startup.  Itanium solves this with guard
>> variables
>> and the emission of multiple initializers, only one of which actually
>> initializes the data at runtime.
>>
>> Microsoft solves this by using a COFF comdat feature called
>> IMAGE_COMDAT_SELECT_**ASSOCIATIVE. The semantics are that the section
>> with this
>> attribute is only linked if the associated section is chosen for the
>> final link.
>> Otherwise it is discarded.
>>
>> In this way, only one initializer is linked and only one entry is
>> produced in
>> the initializer array (.CRT$XCU). Everyone I've spoken with so far
thinks
>> this
>> is basically awesome and is much cleaner than using guard variables. :)
>>
>> I propose changing LangRef to make llvm.global_ctors and
>> llvm.global_dtors be
>> arrays of { i32, void()*, i8* }, where the last field is an optional
>> pointer to
>> a GlobalValue. Old modules containing { i32, void()*} elements will
also
>> be
>> accepted, and the missing third field will be assumed to be null.
>>
>> When performing LTO, if there are multiple entries with the same
>> associated
>> global, only one of them will be kept in the linked module.
>>
>
> will two different globals have different initialization functions too, or
> will
> the same function be reused for many different globals?
>
I'm not sure I follow.  Do you mean, are initialization functions reused
for two globals in the same TU?

Even today, every global with a dynamic initializer gets its own void()
initialization function.  We don't use a single function to initialize
everything.

We need to enforce an ordering on initializers in a single TU, so we have a
function (usually _GLOBAL_I_a) which calls each stub in turn.  After
inlining, most stubs are probably eliminated.

> Thanks, Duncan.
>
>  Similarly, on
>
>> targets supporting this feature (COFF for the moment, but maybe ELF one
>> day as
>> an optimization), LLVM will emit the appropriate comdat bits so that
the
>> system
>> linker behaves similarly. On platforms lacking this support, the old
>> behavior
>> will be used, in which case guard variables are still necessary.
>>
>> This seems fairly uncontroversial, but let me know if anyone objects.
>> I'll try
>> to send patches later this week.
>>
>>
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>>
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130903/d718cb3c/attachment.html>