<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Jun 17, 2016, at 11:27 AM, TB Schardl 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="">Hey Ben,<div class=""><br class=""></div><div class="">Thank you for your comments. I've put my response inline.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">TB</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 17, 2016 at 6:29 AM, Craig, Ben 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=""><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" class=""><span class="">
On 6/16/2016 2:48 PM, Mehdi Amini via llvm-dev wrote:<br class="">
</span><blockquote type="cite" class="">
<br class="">
<div class="">
<blockquote type="cite" class=""><span class="">
<div class="">On Jun 16, 2016, at 9:01 AM, TB Schardl via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<span class=""></span>
</span><span class=""><div class="">
<div dir="ltr" class=""><span class=""><br class="">
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">The CSI framework inserts instrumentation hooks at salient locations throughout the compiled code of a program-under-test, such as function entry and exit points, basic-block entry and exit points, before and after each memory operation, etc. Tool writers can instrument a program-under-test simply by first writing a library that defines the semantics of relevant hooks</span></div>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">and then statically linking their compiled library with the program-under-test.</span></div>
<br class="">
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" class=""><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class="">At first glance, this brute-force method of inserting hooks at every salient location in the program-under-test seems to be replete with overheads. CSI overcomes these overheads through the use of link-time-optimization (LTO), which is now readily available in most major compilers, including GCC and LLVM. Using LTO, instrumentation hooks that are not used by a particular tool can be elided, allowing the overheads of these hooks to be avoided when the</span></div>
</span></div>
</div>
</span></blockquote><span class="">
<div class=""><br class="">
</div>
<div class="">I don't understand this flow: the front-end emits all the
possible instrumentation but the useless calls to the runtime
will be removed during the link?</div>
<div class="">It means that the final binary is specialized for a given
tool right? What is the advantage of generating this useless
instrumentation in the first place then? I'm missing a piece
here...</div>
<br class="">
</span></div>
</blockquote>
Suppose I want to build a production build, and one build for each
of ASAN, MSAN, UBSAN, and TSAN.<br class="">
<br class="">
With the current approach, I need to compile my source five
different times, and link five different times.<br class="">
<br class="">
With the CSI approach (assuming it was the backing technology behind
the sanitizers), I need to compile twice (once for production, once
for instrumentation), then LTO-link five times. I can reuse my .o
files across the sanitizer types.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><div>It is a very artificial advantage, what are you saving? Temporary Disk Space?</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="">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 class=""></div><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><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="">, which would allow tool users to only compile their sources once.</div></div></div></div></div></blockquote><div><br class=""></div><div>LTO means basically “compiles during the link”. You won’t save much.</div><div><br class=""></div><div>I haven’t seen a single compelling argument to *tie* CSI to LTO in this thread until now.</div><div><br class=""></div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></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: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" class="">
<br class="">
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 class=""><font color="#888888" class=""><br class="">
<pre cols="72" class="">--
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 class="">_______________________________________________<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></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>