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

[Duncan Sands]

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
>