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 < [email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
