[Patch][pr19848] Produce explicit comdats in clang

[Reid Kleckner]

Are we sure we want to go this way? MachO can't even represent generalized
comdats. If we want to fix the conflation of weak linkage and implicit
single-member comdat groups, it might be nice to have a lighter weight more
memory efficient way of representing this.

Right now every C++ inline function gets linkonce_odr, a linkage enum
packed into a bitfield to say that it needs a comdat. With this change, we
will copy the long C++ mangled name into a separate symbol table for not
much gain.

Maybe we should turn linkage into a flags enum? Something like ODR,
Discardable, Weak, ImplicitComdat?

On Fri, Dec 19, 2014 at 12:51 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
> There is quiet a bit of history behind this.
>
> The llvm IR until very recently had no support for comdats. This was a
> problem when targeting C++ on ELF/COFF as just using weak linkage
> would cause quiet a bit of dead bits to remain on the executable
> (unless -ffunction-sections, -fdata-sections and --gc-sections were
> used).
>
> To fix the problem, llvm's codegen will just assume that any weak or
> linkonce that is not in an explicit comdat should be output in one
> with the same name as the global.
>
> This unfortunately breaks cases like pr19848 where a weak symbol is
> not expected to be part of any comdat.
>
> Now that we have explicit comdats in the IR, we can finally get both
> cases right.
>
> This first patch just makes clang give explicit comdats to
> GlobalValues where it is allowed to.
>
> A followup patch to llvm will then stop implicitly producing comdats.
>
> 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/20141219/b6617a3a/attachment.html>