[LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors

[Reid Kleckner]

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>