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. >
I'm not sure this is the right direction, but if it is, this change looks reasonable to me. Assuming we want to go in this direction, I think we should also consider switching from a weak linkage to a strong linkage for entities governed by the ODR; using weak linkage is a hack, since these symbols are really not weak in the usual sense. That exposes a hole in our comdat support: we should have the ability to define a discardable comdat (which need not be emitted if none of its symbols are used in the current TU); a discardable comdat with an external function definition seems like the right representation for an inline function.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
