[llvm-dev] ThinLTO and linkonce_odr + unnamed_addr

[Steven Wu via llvm-dev]

> On Feb 15, 2018, at 4:16 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
> 
> Steven Wu <stevenwu at apple.com> writes:
> 
>> I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts
>> 
>> 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden.
> 
> What do those directives mean? I assume .weak_def_can_be_hidden is the
> "you can drop this from the symbol table", but .private_extern I am not
> sure.

.private_extern is just suggesting the symbol has a hidden visibility with none local linkage type/

> 
>> 2. ld64 does treat these two type of symbols differently. For example, ld64 will deduplicate all the can_be_hidden symbols to reduce code size. This can't be achieved when the symbols is private external.
> 
> If I understand you correctly, ld64 will deduplicate
> std::vector<int>::push_back and std::vector<unsigned>::push_back, but it
> will not deduplicate std::vector<HiddenClassA>::push_back and
> std::vector<HiddenClassB>::push_back. Is that correct? Do you know why
> it has that limitation?

ld64 will dedup identical atoms regardless of names which helps in the case of templates with same underlying types.


> 
> Thanks,
> Rafael