[LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors
rnk at google.com
Wed Sep 4 09:16:30 PDT 2013
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
> OK, thanks for explaining. In that case, will multiple instances of the
> global (the ones you want to eliminate) have the same initialization
For the Microsoft C++ ABI, yes, they use the same mangling (?__E*) and are
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
> "global variable" i8* field in llvm.global_ctors, there could instead by a
> third boolean field meaning: collapse multiple instances of this
> function. In fact, maybe it is always OK to remove duplicate
> 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...
More information about the llvm-dev