Re: Avoid double mangling at WHOPR

[Jan Hubicka <hubicka at ucw dot cz>]

> On Sun, 9 Oct 2011, Jan Hubicka wrote:
> 
> > Hi,
> > whopr currently produce local_static.1234.43124 type symbols. This is because
> > everything gets mangled at WPA time and then again at ltrans time.  This simply
> > avoids the second mangling. This save some space & makes WHOPR/non_WHOPR symbol
> > tables comparable more directly.
> > 
> > Bootstrapped/regtested x86_64-linux, also tested with Mozilla LTO, OK?
> 
> Hmmm.  I'd really like to defer mangling to LTRANS at one point, as
> we will know if there will be conflicts of local symbols at that point
> (another point would be the partitioning code).  So this patch goes
> backward ... (ideally a first step would move it to symbol resolution
> time, another place where we can check for conflicts, and then only
> apply it a LTRANs stage).

Actually it seems to me that mangling at WPA makes more sense - you don't get
symbol name sensitive on partitioning decisions so things go a bit more
consistently. Partitioning depends on global properties of program so any code
that depends on particular partitioning decisions will have tendency to
randomly break and unbreak.

We can not really make any promises about our ability to not mangle particular
symbol (for use in asm code or whatever):  we need to mangle on the occasion of
conflict with another static symbol but also when we decide to promote it
hidden. We have no information about another hidden symbol in the non-LTO
world.  Either linker plugin API needs to be extended by providing us with list
of forbidden names or ability to have "hidden in LTO world" visibility or we
probably need to start using random seeds on all promoted symbols.
(in fact I already do sort of mangling to avoid conflict on comdats that has been
brought local and then again promoted global, I just did not noticed it is a general
problem back then when I first saw the linker complaining).

Honza