<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 17, 2019 at 7:36 AM Iurii Gribov <<a href="mailto:Iurii.Gribov@ceva-dsp.com">Iurii.Gribov@ceva-dsp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(cc list this time)<br>
<br>
Hi Teresa,<br>
<br>
Apologies if this has been discussed before but ...<br>
<br>
> The LTO visibility of a class is derived at compile time from the class’s symbol visibility.<br>
> Generally, only classes that are internal at the source level (e.g. declared in an anonymous namespace) receive hidden LTO visibility.<br>
> Compiling with -fvisibility=hidden tells the compiler that, unless <br>
> otherwise marked, symbols are assumed to have hidden visibility, which <br>
> also implies that all classes have hidden LTO visibility (unless decorated with a public visibility attribute).<br>
> This results in much more aggressive devirtualization.<br>
<br>
Note that by default, unlike GCC, LLVM is liberal on visibility-constrained optimizations. In particular it freely performs inlining, IPA and cloning on them (see <a href="https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html</a> which also suggested adding -fsemantic-interposition to actually respect visibility in optimizations). It's unclear why devirtualization should behave differently than other optimizations (at least by default).<br></blockquote><div><br></div><div>Are you suggesting that we should be more aggressive by default (i.e. without -fvisibility=hidden or any new options)? I believe that will be too aggressive for class LTO visibility.  It is common to override a virtual functions across shared library boundaries (e.g. a test may override a virtual function from a shared library with a mock class). But with what I am proposing we will assume it is safe under the proposed LTO link option, which should be applied when linking statically other than e.g. system libraries.</div><div><br></div><div>Thanks,</div><div>Teresa</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-I<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-family:Times;font-size:medium"><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:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"><br></td></tr></tbody></table></span></div></div></div></div>