
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 30, 2016, at 4:25 PM, Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <span dir="ltr" class=""><<a href="mailto:chisophugis@gmail.com" target="_blank" class="">chisophugis@gmail.com</a>></span> wrote:<br class=""></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I believe the relocation stuff that Rafael is currently working on will make this a non-issue (it will make relocation application much friendlier for the CPU).</div></blockquote><div class=""><br class=""></div><div class="">I don't think Rafael's patch would make this a non-issue. He's making scanRelocs to create data, which would reduce the number of calls to the virtual functions, but it wouldn't be reduced to zero.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">However, even in the current scheme, since the target is fixed, all the indirect call sites should be monomorphic and so there shouldn't be much branch-prediction cost (certainly nothing that would cause 1.8% performance delta for the entire link).</div></div></blockquote><div class=""><br class=""></div><div class="">Agreed. We could template functions that call TargetInfo's member functions for each target to eliminate the virtual function calls.</div></div></div></div></div></blockquote><div><br class=""></div><div>Are you measuring with a build of LLD with LTO+PGO (+ICP+WholeDevirtualization...)?</div><div>We have compiler technologies to address these problems, I think we'd better leave it to them when they can handle it.</div><div><br class=""></div><div>--</div><div> Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Notice that 1.8% is smaller than the performance variation from <span style="font-size:12.8px" class="">r263227 which is a very innocuous-looking change but caused </span><span style="font-size:12.8px" class="">~2-3% slowdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)").</span><br class=""></div><div class=""><div class=""><br class=""></div><div class="">-- Sean Silva</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="h5"><div dir="ltr" class="">I was wandering how much is the overhead of virtual function calls of TargetInfo member functions. TargetInfo handles platform-specific details, and we have target-specific subclasses of that class. The subclasses override functions defined in TargetInfo.<div class=""><br class=""><div class="">The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That is a motication to do the following test.<div class=""><br class=""></div><div class="">As a test, I removed all TargetInfo subclasses except for x86-64, move all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from TargetInfo.</div><div class=""><br class=""></div><div class="">The original LLD links itself (with debug info) in 7.499 seconds. The de-virtualized version did the same thing in 7.364 seconds. So it can improve it by 1.8%.</div><div class=""><br class=""></div><div class="">I'm just pointing out that there's room there to improve performance, and I'm not suggesting we do something for this right now. We probably shouldn't do anything for this because the current code is pretty straightforward. But I'd expect that we will eventually want do something for this in future.</div></div></div></div>

<br class=""></div></div>_______________________________________________<br class="">

LLVM Developers mailing list<br class="">

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">

<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">

<br class=""></blockquote></div><br class=""></div>

</blockquote></div><br class=""></div></div>

_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>