search for: weak_def_can_be_hidden

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. > 2...

...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 no...

...e.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_ex...

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. 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 achie...

Interesting. Now I understand the full picture. For MachO, linker is picking based on atoms so it picks the atom with more visibility which doesn’t have the constraint you mentioned. Let me do some more digging. Worst case I will add a different rule for MachO but it might be fine. Steven > On Feb 9, 2018, at 1:40 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >

...: >>> >>>> 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...

...hide": it just > means that the address is not taken in the current compilation unit IIRC. > The linker decides that it can hide it in the DSO if none of the > compilation unit is using the address based on this auto-hide flag. > > Does it make sense? > Yeah, I missed that. .weak_def_can_be_hidden is a MachO thing that I'm not familiar with. It's nice that the format supports it. :) Perhaps instead we should make ThinLTO responsible for doing the auto-hiding, then? It could do the check of, are all declarations marked local_unnamed_addr, if so, make it weak_odr + unnamed_addr + visi...

...dev <llvm-dev at lists.llvm.org> wrote: > > 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. > 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...

...vm.org> wrote: > > > > 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. > > 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...

> From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. I think there is a nuance, it