> > 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). > > Ok, I see why it makes sense on WPA time. But then why not mangle > during partitioning? I think it still makes sense to avoid mangling local > decls, if not for debugging experience.
Yeah, we could do that. Debugging experience is quite good reason (though it will also make bogus asm statements magically work and break on random basis. In a way just breaking them seems more sensible behaviour to me ;) ). > > We do mangle late when we bring symbols local anyway, no? I also > seem to remember we mangle at LTO time, too ... Hmm, I think we mangle at stream in since we do make hashtables based on symbol names that are supposed to be unique, but perhaps I am wrong. LTO time you mean at compilation time when streaming out? I am not aware of that. Honza > > Richard.
