[patch] Add support for putting constructors and destructos in explicit comdats

[Reid Kleckner]

I don't like calling arrangeCXXDtorDeclaration from ctor-related functions.
It looks like a typo. In the past I've used 'structor' as the generic term
for ctors and dtors. You can see it in the Itanium mangling code, but I
don't think it's very widely used. Does that seem like a better
nomenclature? Then we would probably have StructorType, etc.

I'm excited to finally have this functionality, though. :)


On Thu, Sep 4, 2014 at 11:20 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> I have rebased this patch on top of my refactoring patch since it
> makes it quiet a bit simpler. I have attached both.
>
> Because of some bugs in GCC there is a discussion going on
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306 about the best way
> to handle the destructor comdat. The attached patch implements the
> suggestion of using a new comdat name.
>
>
> On 1 September 2014 23:03, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
> > There are situations when clang knows that the C1 and C2 constructors
> > or the D2 and D2 destructors are identical. We already optimize some
> > of these cases, but cannot optimize it when the GlobalValue is
> > weak_odr.
> >
> > The problem with weak_odr is that an old TU seeing the same code will
> > have a C1 and a C2 comdat with the corresponding symbols. We cannot
> > suddenly start putting the C2 symbol in the C1 comdat as we cannot
> > guarantee that the linker will not pick a .o with only C1 in it.
> >
> > The solution implemented by GCC is to expand the ABI to have a comdat
> > whose name uses a C5/D5 suffix and always has both symbols. That is
> > what this patch implements.
> >
> > We could also use C5/D5 for linkonce_odr, but it is probably better to
> > change one at a time.
> >
> > Cheers,
> > Rafael
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140904/8df1a794/attachment.html>