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

[Rafael Espíndola]

> 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.

> -Eli

Cheers,
Rafael