<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-02-08 9:33 GMT-08:00 Steven Wu <span dir="ltr"><<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.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 style="word-wrap:break-word;line-break:after-white-space"><br><div><span class="gmail-"><br><blockquote type="cite"><div>On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:</div><br class="gmail-m_1453645400431904931Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-02-07 12:45 GMT-08:00 Steven Wu <span dir="ltr"><<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.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 style="word-wrap:break-word;line-break:after-white-space"><br><div><span><br><blockquote type="cite"><div>On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:</div><br class="gmail-m_1453645400431904931m_4532309694006632950Apple-interchange-newline"><div><div dir="ltr">> <span style="font-size:12.800000190734863px">But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well.</span><div class="gmail-m_1453645400431904931m_4532309694006632950gmail-yj6qo gmail-m_1453645400431904931m_4532309694006632950gmail-ajU" style="font-size:12.800000190734863px"></div><div class="gmail_extra"><br></div><div class="gmail_extra">What do you mean that the promotion can break that?</div><div class="gmail_extra"><br></div><div class="gmail_extra">The original description I found here: <a href="https://reviews.llvm.org/D20348" target="_blank">https://reviews.llvm.org<wbr>/D20348</a> says that i<span style="font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">t is </span><span style="font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">possible to exclude a global from the symbol table if three things are true:</span></div><div class="gmail_extra"><ul class="gmail-m_1453645400431904931m_4532309694006632950gmail-remarkup-list" style="margin:12px 0px 12px 30px;padding:0px;border:0px;list-style-position:initial;font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><li class="gmail-m_1453645400431904931m_4532309694006632950gmail-remarkup-list-item" style="margin:0px;padding:0px;border:0px;line-height:1.7em">This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address)</li><li class="gmail-m_1453645400431904931m_4532309694006632950gmail-remarkup-list-item" style="margin:0px;padding:0px;border:0px;line-height:1.7em">The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same)</li><li class="gmail-m_1453645400431904931m_4532309694006632950gmail-remarkup-list-item" style="margin:0px;padding:0px;border:0px;line-height:1.7em">It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global)</li></ul><div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol, Lato, Helvetica Neue, Helvetica, Arial, sans-serif"><br></font></div><div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol, Lato, Helvetica Neue, Helvetica, Arial, sans-serif">When promoting from a linkonce_odr, it seems safe to me to *keep* the </font><span style="font-size:12.800000190734863px">local_unnamed_addr on the weak_odr since we know the symbol was linkonce_odr in the first place.</span></div></div></div></div></blockquote><div><br></div></span><div>I don't think there is such guarantees. The description doesn't prevent local_unnamed_addr on other linkage types. If your assumption is correct, then the description can simply state "symbols with local_unnamed_addr can be hidden from the symbol table, regardless of the linkage type). I guess I will leave pcc to interpret this.</div><div><br></div><div>If my interpretation is correct, then a constant with linkonce_odr + local_unnamed_addr can be hidden from symbol table before promotion. After promotion, it no longer satisfies rule 2, so it has be in the symbol table.</div></div></div></blockquote><div><br></div><div>I don't see what would justify this, but I can miss some subtleties here.</div><div>If we can't do this with promotion, then it would be very unfortunate: the whole point of these was to allow to "auto-hide".</div></div></div></div></div></blockquote><div><br></div></span><div>I think thinLTO should handle unnamed_addr and generate auto hide if needed. We can put (local_)unnamed_addr into GlobalSummary and teach thinLTO to add visibility hidden for symbols that satisfies the condition. I don't think this is very hard to do.</div><div><br></div><div>I don't know if we have a definition for unnamed_addr. Do we treat it local_unnamed_addr that automatically satisfy condition #1? Then promote linkonce_odr + unnamed_addr into weak_odr + unnamed_addr + hidden is a correct transform then.</div></div></div></blockquote><div><br></div><div>> promote linkonce_odr + unnamed_addr into weak_odr + unnamed_addr + hidden is a correct transform then.</div><div><br></div><div>I believe it is only possible to hide if the symbol isn't required to be preserved by the linker.</div><div>But in this case we should always be able to hide regardless of the linkage don't we?</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div> </div><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 style="word-wrap:break-word;line-break:after-white-space"><div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Steven</div></font></span><div><div class="gmail-h5"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><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 style="word-wrap:break-word;line-break:after-white-space"><div><div><div class="gmail-m_1453645400431904931h5"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">-- </span></div><div><span style="font-size:12.800000190734863px">Mehdi</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-07 12:12 GMT-08:00 Steven Wu <span dir="ltr"><<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.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 style="word-wrap:break-word;line-break:after-white-space">We didn't drop unnamed_addr. I just don't think weakodr_addr + unnamed_addr is safe to hide in all cases.<div><br></div><div>I don't know if I interpreted local_unnamed_addr correctly but I think it is mostly the same in thinLTO for ld64. The code generator only looks at the individual module and ld64 will be in charge of merging all the symbols with autohide. It doesn't really help in this case. But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well.</div><span class="gmail-m_1453645400431904931m_4532309694006632950gmail-HOEnZb"><font color="#888888"><div><br></div><div>Steven</div></font></span><div><div class="gmail-m_1453645400431904931m_4532309694006632950gmail-h5"><div><div><div><br></div><div><br><div><br><blockquote type="cite"><div>On Feb 7, 2018, at 11:44 AM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:</div><br class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222Apple-interchange-newline"><div><div dir="ltr">Something I haven't seen mentioned: why are we dropping the unnamed_addr? Can't we preserve it with the weak symbol? Would it be OK to add auto-hide in this case (maybe it would already happen)?<div>Can we use the new local_unnamed_addr that was added (by pcc or Rafael I don't remember)? I think this attribute matches exactly the `auto-hide` semantic. Wasn't the idea that this could be added any time by a module-level `infer_attribute` pass?</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-07 11:36 GMT-08:00 Steven Wu via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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 style="word-wrap:break-word;line-break:after-white-space">I didn't realize that that WeakDefCanBeHiddenDirective is only available on Darwin. So if we are doing it for #2, it should be a Darwin only fix as well.<div><br></div><div>Steven<div><div class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222h5"><br><div><br><blockquote type="cite"><div>On Feb 7, 2018, at 11:29 AM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:</div><br class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222m_3222406152827683329Apple-interchange-newline"><div><div dir="ltr">I agree with Teresa, we should probably do #2 to preserve behavior for now.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 9:34 AM, Teresa Johnson 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Steven,<div><br></div><div>I'd prefer not to inhibit importing. I am also concerned about putting these symbols in the llvm.compiler_used (I don't recall earlier discussion around this, but it seems like it could have effects on optimization as you mention).</div><div><br></div><div>What are the downsides of #2 (adding visibility hidden)? We already do this when promoting internal linkage to external due to importing. I'm not an expert on how this would affect link semantics. </div><div><br></div><div>Thanks,</div><div>Teresa</div></div><div class="gmail_extra"><span><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu <span dir="ltr"><<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.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">Hi,<br>
<br>
I recently found that thinLTO doesn't deal with globals that has linkonce_odr and unnamed_addr (for macho at least) because it prohibits the autohide optimization during link time.<br>
<br>
In LLVM, we tagged a global linkonce_odr and unnamed_addr to indicate to the linker can hide them from symbol table if they were picked (aka, linkonce_odr_auto_hide linkage). It is very commonly used for some type of Tables for c++ code in clang for example.<br>
However, thinLTO is promoting these symbols to weak_odr + unnamed_addr, which lose the property. As a result, it introduces unnecessary weak external symbols and weak external are not good for performance on darwin platforms.<br>
<br>
I have few proposed solutions for this issue but I don't know which one works the best for none macho platforms and other LTO clients like lld.<br>
<br>
1. Use llvm.compiler_used.<br>
As far as I know, the linkage promote are just there to keep the symbol through internalize and codegen so adding them to compiler used should solve this issue. I was told that there was some objections to do that in the first place. Is it because the globals added to compiler used is ignored by the optimizer so they cannot be internalized and they cannot be optimized away? This works well for the case I am looking at because c++ VTable can't really be optimized and for darwin platforms because we can rely on ld64 to do dead_stripping if needed.<br>
<br>
2. Add visibility hidden when promote linkonce_odr + unnamed_addr.<br>
Well,this doesn't really preserve the link semantics, but neither does promoting linkonce_odr to weak_odr. The global will still end up in the symbol table but at least it isn't external so it doesn't come with a performance cost.<br>
<br>
3. We can teach function importer that it cannot just reference to linkonce_odr + unnamed_addr symbols without importing them. I have some thoughts about how to do this so I can propose something if people are interested going down this route. I am expecting at least add an entry in the global summery and change the cost of importing symbols that references to linkonce_odr + unnamed_addr symbols.<br>
<br>
4. As a temporary fix, just targeting at the VTables for c++. We can put a special case for global constants that uses this linkage so they are never promoted and their parents are never imported into other modules. The benefit for inlining global constants is very minimal and I don't think we are doing it currently.<br>
<br>
Let me know if any of those solutions work for other LTO client.<br>
<br>
Thanks<br>
<span class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222m_3222406152827683329m_6675062855887638999HOEnZb"><font color="#888888"><br>
Steven<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></span><span class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222m_3222406152827683329HOEnZb"><font color="#888888">-- <br><div class="gmail-m_1453645400431904931m_4532309694006632950gmail-m_-6843703071431001222m_3222406152827683329m_6675062855887638999gmail_signature"><span style="font-family:Times;font-size:inherit"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:(408)%20460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>