<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 14, 2018 at 2:26 PM, Duncan P. N. Exon Smith via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
> On Feb 14, 2018, at 09:55, Steven Wu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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<br>
><br>
> 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.<br>
> 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.<br>
<br>
</span>For others' context, this deduplication in ld64 will effectively merge (e.g.) std::vector<int>::push_back with std::vector<unsigned>::push_<wbr>back based on function content hashes.<br>
<br>
It would be a shame to block this optimization because of #1 – it seems like there should be a way to work around that.  Perhaps there's something we can change in ld64.<br></blockquote><div><br></div><div>As far as I can tell, the "auto hide" property is independent of whether the symbol is actually hidden (the former is N_WEAK_DEF|N_WEAK_REF in n_desc, and the latter is N_PEXT in n_type). So perhaps what you can do is change ld64 to recognize N_WEAK_DEF|N_WEAK_REF together with N_PEXT as meaning "hidden and mergeable".</div><div><br></div><div>Peter</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> Steven<br>
><br>
>> On Feb 9, 2018, at 2:00 PM, Steven Wu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> Steven<br>
>><br>
>>> On Feb 9, 2018, at 1:40 PM, Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>>><br>
>>> Steven Wu <<a href="mailto:stevenwu@apple.com">stevenwu@apple.com</a>> writes:<br>
>>><br>
>>>> Rafael, another question for you. IRLinker currently takes min visibility for the symbol (lib/Linker/LinkModules.cpp:<wbr>120). Should it take the max visibility? At least that is what ld64 is doing and is somewhat related to this change because I want to make sure the behavior is consistent if we mark more stuff as hidden.<br>
>>><br>
>>> No, it should take the min visibility to be consistent with the ELF<br>
>>> spec. The spec says<br>
>>><br>
>>> If different visibility attributes are specified for distinct<br>
>>> references to or definitions of a symbol, the most constraining<br>
>>> visibility attribute must be propagated to the resolving symbol in the<br>
>>> linked object.<br>
>>><br>
>>> The reason the ELF spec mandates the minimum is that a .o having a<br>
>>> hidden symbol foo means that that file can access foo in a way that is<br>
>>> only valid under the assumption it is local. It not might change the pic<br>
>>> register before doing a call for example.<br>
>>><br>
>>> Cheers,<br>
>>> Rafael<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>