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

[Reid Kleckner]

On Wed, Sep 4, 2013 at 4:11 AM, Duncan Sands <baldrick at free.fr> wrote:

>  Even today, every global with a dynamic initializer gets its own void()
>> initialization function.  We don't use a single function to initialize
>> everything.
>>
>
> OK, thanks for explaining.  In that case, will multiple instances of the
> same
> global (the ones you want to eliminate) have the same initialization
> function?
>

For the Microsoft C++ ABI, yes, they use the same mangling (?__E*) and are
linkonce_odr.

For the Itanium C++ ABI, no, they are all internal and hence different.  It
uses a guard variable to avoid double initialization.


> If so, then I guess right now, without your changes, llvm.global_ctors will
> have multiple copies of the same function.  Then instead of introducing a
> third
> "global variable" i8* field in llvm.global_ctors, there could instead by a
> third boolean field meaning: collapse multiple instances of this
> initialization
> function.  In fact, maybe it is always OK to remove duplicate
> initialization
> functions in llvm.global_ctors?
>

Richard and I considered this, but cl.exe associates the .CRT$XCU function
pointer with the global, and not the initializer function.  I could try to
recover the name of the global from the name of the initializer, but this
seems fairly terrible, and possibly invalid in the face of GlobalOpt.

Consider a constructor which does nothing but tail call to 'void foo()'.
 It should be valid to make the .CRT$XCU function pointer point directly to
foo and delete the initializer.  We could outlaw this optimization when the
unique bit is set, but then I still have to recover the global's symbol to
get the MS C++ ABI right.

That said, if I only needed one bit, I could steal it from the i32 priority
field which only uses 16 bits.  =D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130904/348a4d52/attachment.html>