> 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
