<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 17, 2016 at 9:29 AM, Craig, Ben 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 bgcolor="#FFFFFF" text="#000000"><span class="">
On 6/16/2016 2:48 PM, Mehdi Amini via llvm-dev wrote:<br>
</span><blockquote type="cite">
<br>
<div>
<blockquote type="cite"><span class="">
<div>On Jun 16, 2016, at 9:01 AM, TB Schardl via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<span></span>
</span><span class=""><div>
<div dir="ltr"><span><br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">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"><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">and then statically linking their compiled library with the program-under-test.</span></div>
<br>
<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">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><br>
</div>
<div>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>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>
</span></div>
</blockquote>
Suppose I want to build a production build, and one build for each
of ASAN, MSAN, UBSAN, and TSAN.<br>
<br>
With the current approach, I need to compile my source five
different times, and link five different times.<br>
<br>
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.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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.</div></blockquote><div><br></div><div>Other than the build time, we should also consider the performance of the produced binary, which might be more important.</div><div>I have hard time to believe that the LTO-link optimized (CSI version 1) binary could beat the original ASan IR instrumentation based binary.</div><div>With IR instrumentation, the binary could benefit both from problem specific domain knowledge and comprehensive compiler optimizations:</div><div>e.g., inline small code without context switch, skip redundant load/store instrumentation, and more aggressive optimization since the compiler sees everything.</div><div>I am not sure if CSI could do any of them.</div><div>IMHO, CSI might be good for fast prototype research work and may fall short when we are really serious about the performance.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><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">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>