<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Mehdi, I think TB is saying that LTO is actually *more* incremental than standard compilation for people writing instrumentation tools.</div><div class="gmail_quote"><br></div><div class="gmail_quote">It's far simpler to rebuild your CSI instrumentation hooks and re-run LTO on Apache than it is to re-run someone else's complicated build system. In fact, you save all the time that clang would spend parsing C and C++ source code, since you're starting with several blobs of semi-optimized LLVM IR.</div><div class="gmail_quote"><br></div><div class="gmail_quote">It's worth exploring what you mentioned up-thread, where you inline the instrumentation into the code during normal compliation instead of waiting until link time, but I think it makes more sense to make it easy to build tools before we try to make those new tools compile faster. It seems like a nice-to-have feature for instrumentation tools that manage to graduate from research idea to production tool.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Jun 17, 2016 at 11:42 AM, Mehdi Amini 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This reduction in the number of compile operations needed, and in the number intermediate object/bitcode files produced, is indeed an advantage of the CSI approach. </div></div></div></div></div></blockquote><div><br></div></span><div>It is a very artificial advantage, what are you saving? Temporary Disk Space?</div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>As an aside, we've been experimenting with linking CSI-instrumented bitcodes against the "null tool," which implements every instrumentation hook as a nop, and comparing the performance of those binaries against production binaries. Our preliminary tests have shown some promising results. For generating main executables, using LTO to link CSI-instrumented bitcodes with the null tool produces executables that are as fast as the production executables. For generating dynamic libraries, however, using LTO to link the CSI-instrumented bitcode of a dynamic library with the null tool seems to produce a binary that is slower than production. (The Apache HTTP server benchmark we've tried runs roughly 30% slower when using such null-tool-instrumented dynamic libraries.) These results suggest that using LTO to link CSI-instrumented bitcodes with the null tool is almost, but not quite, able to produce binaries with production performance</div></div></div></div></div></blockquote><div><br></div></span><div>These results suggests that “adding instrumentation has a cost” nothing more, and is unrelated to LTO at all.</div><div>You would provide the runtime to the compiler directly during the compile phase and you would get the same results.</div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>, which would allow tool users to only compile their sources once.</div></div></div></div></div></blockquote><div><br></div></span><div>LTO means basically “compiles during the link”. You won’t save much.</div><div><br></div><div>I haven’t seen a single compelling argument to *tie* CSI to LTO in this thread until now.</div><div><br></div><div><br></div><div>— </div><div>Mehdi</div><span class=""><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 bgcolor="#FFFFFF" text="#000000">
<br>
It's possible that the math doesn't really work out in practice if
the cost of the LTO-link dwarfs the compile times.<span><font color="#888888"><br>
<pre cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</font></span></div>
<br>_______________________________________________<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/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<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" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></span></div><br></div><br>_______________________________________________<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/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>