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

[Eli Friedman]

On Wed, Sep 4, 2013 at 2:14 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> > 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.)
>
> True. I was trying to come up with a case where this would kick in
> from C++ and existing optimizations, but got the example wrong. I
> first noticed the problem when trying to extend the logic to handle
> non unnamed_addr symbols that just happen to not have the address
> taken, in which case it is easy to construct an example where an ELF
> linker produces a hidden symbol and we want a default one.
>
> The "low level" problem still exists, since the IR spec doesn't
> required unnamed_addr to be in sync. For example, given
>
> TU1:
> linkonce_odr unnamed_addr @foo....
>
> TU2:
> linkonce_odr @foo.....
>
> we would end up with a hidden symbols in TU1 and the linker then
> produces a hidden symbol in the final output, which is invalid because
> of TU2.
>
>
We could just specify this the other way: if we have two definitions and
either is unnamed_addr, the merged definition is also unnamed_addr.  Is
there some reason we shouldn't?

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