[llvm] r189954 - Revert "Add r159136 back now that pr13124 has been fixed."

Eli Friedman eli.friedman at gmail.com
Wed Sep 4 13:38:17 PDT 2013


On Wed, Sep 4, 2013 at 9:09 AM, Rafael Espindola <rafael.espindola at gmail.com
> wrote:

> Author: rafael
> Date: Wed Sep  4 11:09:01 2013
> New Revision: 189954
>
> URL: http://llvm.org/viewvc/llvm-project?rev=189954&view=rev
> Log:
> Revert "Add r159136 back now that pr13124 has been fixed."
>
> This reverts commit r189886.
>
> I found a corner case where this optimization is not valid:
>
> Say we have a "linkonce_odr unnamed_addr" in two translation units:
> * In TU 1 this optimization kicks in and makes it hidden.
> * In TU 2 it gets const merged with a constant that is *not* unnamed_addr,
>   resulting in a non unnamed_addr constant with default visibility.
>
> 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.)

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130904/7bf57fa5/attachment.html>


More information about the llvm-commits mailing list