<div dir="ltr">On Wed, Sep 4, 2013 at 3:09 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> We could just specify this the other way: if we have two definitions and<br>
> either is unnamed_addr, the merged definition is also unnamed_addr.  Is<br>
> there some reason we shouldn't?<br>
<br>
</div>Disallows so merging opportunities and enables other optimizations,<br>
but I don't think it would enable this one.  In the above example<br>
<div class="im"><br>
TU1:<br>
linkonce_odr unnamed_addr @foo....<br>
<br>
TU2:<br>
linkonce_odr @foo.....<br>
<br>
</div>I was assuming that each TU produces an ELF file. The ELF linker knows<br>
nothing about unnamed_addr and will just produce a hidden symbol for<br>
foo. For this optimization to be legal we would have to require the<br>
frontends to produce a "linkonce_odr unnamed_addr" in all copies of a<br>
symbol or none.<br><br></blockquote><div>Err, yes, what I meant was to require that every definition honor unnamed_addr semantics if any definition does (whether not it's actually marked with unnamed_addr).  But that would probably be more confusing than useful.</div>
<div><br></div><div>-Eli</div></div></div></div>