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

[Eli Friedman]

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

> > 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?
>
> Disallows so merging opportunities and enables other optimizations,
> but I don't think it would enable this one.  In the above example
>
> TU1:
> linkonce_odr unnamed_addr @foo....
>
> TU2:
> linkonce_odr @foo.....
>
> I was assuming that each TU produces an ELF file. The ELF linker knows
> nothing about unnamed_addr and will just produce a hidden symbol for
> foo. For this optimization to be legal we would have to require the
> frontends to produce a "linkonce_odr unnamed_addr" in all copies of a
> symbol or none.
>
> 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.

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