[llvm] r209015 - Add comdat key field to llvm.global_ctors and llvm.global_dtors

Reid Kleckner rnk at google.com
Wed Jun 4 14:04:19 PDT 2014


On Wed, Jun 4, 2014 at 1:21 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com
> wrote:

> > Add comdat key field to llvm.global_ctors and llvm.global_dtors
> >
> > This allows us to put dynamic initializers for weak data into the same
> > comdat group as the data being initialized.  This is necessary for MSVC
> > ABI compatibility.  Once we have comdats for guard variables, we can use
> > the combination to help GlobalOpt fire more often for weak data with
> > guarded initialization on other platforms.
>
> So having
>
>   %ini { i32 65535, void ()* @b_global_ctor, i8* bitcast (i32* @b to i8*) }
>
> in @llvm.global_ctors is effectively a way of declaring that
> b_global_cto should have the same comdat as @b?
>

I didn't implement the CodeGen part of this for ELF, but it should be
pretty trivial.  It doesn't change the comdat of the initializer function.
 It changes the comdat of the *pointer to the initializer in .init_array or
.CRT$XCU* to be the same as @b.


> Is this a short term solution? How will this interact with sections
> having an explicit comdat in the future?
>

It's a long term solution because we want to keep the representation of
initializers high-level and platform neutral so that GlobalOpt can hack on
it.  At least, that's the direction that Nick pushed for.

Once we have explicit sections with comdats, as an alternative, we could
simply emit function pointer globals with an explicit section and comdat.
 The downside is that GlobalOpt would have to be taught how to understand
.init_array, .ctors, .CRT$XCU, and whatever MachO uses.

BTW, the itanium abi wording is a bit strange, but I don't think we
> can change the comdat of the function. What we can (and should) do is
> put the guard in the same comdat as the variable.


While the code as is doesn't put the initializer function into a comdat,
why do you think we can't do this?  It seems like it'd be a nice code size
optimization.  Right now the initializer function has internal linkage
because there is no mangling for it in Itanium, and we end up with lots of
unmerged duplicate code.

My plan for the future is to put both the initializer function and the
guard variable into the comdat group of the data being initialized using
section IR.  Then either GlobalOpt or Clang can replace the global with a
constant, so long as the initializer of the guard variable is updated.


> ----------------------------------------------
> Some objects with static storage duration have associated guard
> variables used to ensure that they are initialized only once (see
> 3.3.2). If the object is emitted using a COMDAT group, the guard
> variable must be too. It is suggested that it be emitted in the same
> COMDAT group as the associated data object, but it may be emitted in
> its own COMDAT group, identified by its name. In either case, it must
> be weak.
> ----------------------------------------------
>
> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140604/32d6bc2b/attachment.html>


More information about the llvm-commits mailing list