<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 19, 2014 at 12:51 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is quiet a bit of history behind this.<br>
<br>
The llvm IR until very recently had no support for comdats. This was a<br>
problem when targeting C++ on ELF/COFF as just using weak linkage<br>
would cause quiet a bit of dead bits to remain on the executable<br>
(unless -ffunction-sections, -fdata-sections and --gc-sections were<br>
used).<br>
<br>
To fix the problem, llvm's codegen will just assume that any weak or<br>
linkonce that is not in an explicit comdat should be output in one<br>
with the same name as the global.<br>
<br>
This unfortunately breaks cases like pr19848 where a weak symbol is<br>
not expected to be part of any comdat.<br>
<br>
Now that we have explicit comdats in the IR, we can finally get both<br>
cases right.<br>
<br>
This first patch just makes clang give explicit comdats to<br>
GlobalValues where it is allowed to.<br>
<br>
A followup patch to llvm will then stop implicitly producing comdats.<br></blockquote><div><br></div><div>I'm not sure this is the right direction, but if it is, this change looks reasonable to me.</div><div><br></div><div>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.</div></div></div></div>