<div dir="ltr">On Wed, Sep 4, 2013 at 9:09 AM, Rafael Espindola <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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Author: rafael<br>
Date: Wed Sep  4 11:09:01 2013<br>
New Revision: 189954<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=189954&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=189954&view=rev</a><br>
Log:<br>
Revert "Add r159136 back now that pr13124 has been fixed."<br>
<br>
This reverts commit r189886.<br>
<br>
I found a corner case where this optimization is not valid:<br>
<br>
Say we have a "linkonce_odr unnamed_addr" in two translation units:<br>
* In TU 1 this optimization kicks in and makes it hidden.<br>
* In TU 2 it gets const merged with a constant that is *not* unnamed_addr,<br>
  resulting in a non unnamed_addr constant with default visibility.<br><br></blockquote><div>If we have a linkonce_odr unnamed_addr constant A and an internal non-unnamed_addr constant B, it isn't a legal transformation to drop the unnamed_addr from A and change the references to B to refer to A instead.  Imagine what would happen if we performed this transformation in two translation units. :)  (It would be legal to simply drop A, and change all the references to refer to B instead, but that doesn't cause any issues in the scenario you present.)</div>
<div><br></div><div>-Eli</div></div></div></div>