<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-02-07 13:23 GMT-08:00 Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Feb 7, 2018 at 11:35 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-m_-8989425376159839642gmail-">> <span style="font-size:12.8px">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.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">I think there is a nuance, it is marking these as "auto-hide": it just means that the address is not taken in the current compilation unit IIRC.</span></div><div><span style="font-size:12.8px">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.</span></div><div><br></div><div>Does it make sense?</div></div></blockquote><div><br></div></span><div>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. :)</div><div><br></div><div>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 + visibility=hidden?</div></div></div></div></blockquote><div><br></div><div>Possibly, I don't remember the details of the plan: it may depend if the symbol is required by the linker to be exported outside of the DSO?<br></div><div><br></div><div>This situation (and similar others about linkage changes) is a large part of what motivated originally the new "resolution" LTO API: it offers a much finer grain for the linker to express the constraint around this. The goal was to be able to make these decisions very accurately regardless of the situation. For instance a symbol in LTO can be referenced from a non-LTO object file, but isn't exported outside of the current linkage unit / DSO, so it does not need to be exported publicly. Unfortunately IIRC this can't be expressed in the "old" LTO API that is expose in the C interface / libLTO.</div><div><br></div><div>Now for cases where we *already* have unnamed_addr (i.e. not only local_unnamed_addr) in the IR like here, we should be able to use this information regardless of the linker resolutions (I think), at least to generate auto-hide.</div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div></div><br></div></div>