<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 20, 2016, at 7:00 PM, 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=""><div class="">Hey David,<br class=""></div><div class=""><div class=""><br class=""></div><div class="">Thank you for your feedback. I'm trying to understand the model you sketched in order to compare it to CSI's current approach, but the details of your proposal are still fuzzy to me. In particular, although the model you described would avoid using LTO to elide unused hooks, it seems more complicated for both tool writers and tool users to use. Please clarify your model and shed some light on the questions below.</div><div class=""><br class=""></div><div class="">1) What does the "CSI dev tool" you describe look like? In particular, how does the tool writer produce and maintain an export list of non-stub hook definitions for her tool? Maintaining an export list manually would seem to be an error-prone hassle. One could imagine generating the export list automatically with a custom compile-time pass that the tool-writer runs, but maintaining consistency between a tool and its export list remains a concern for both the tool writer and the tool user.</div><div class=""><br class=""></div><div class="">2) To clarify, in your scheme, the tool writer produces an export list as well as an object/bitcode for the tool. The tool user compiles the program-under-test using the export list, and then incorporates the tool object/bitcode at link time. Is this what you have in mind?</div><div class=""><br class=""></div><div class=""><div class=""><div class="">3) Do I understand correctly that your model only gets rid of the need for LTO to elide unused instrumentation hooks? In particular, are other optimizations on the instrumentation still contingent on LTO (or ThinLTO)? One nice feature of the current design is that tool writers can use properties passed to hooks to elide instrumentation conditionally based on common static analysis. It looks like optimizations based on properties are still possible in the model you propose, but as with the current design, they would still rely on LTO or ThinLTO.</div><div class=""><br class=""></div><div class="">4) In your model, if the tool user wants to analyze his program with several different tools, then he must recompile his program from source once for each tool. Is this correct? The argument in this thread seems to be that recompiling the program from source is no worse than using LTO because LTO incurs high overhead. (From the results I've found online <a href="http://llvm.org/devmtg/2015-04/slides/ThinLTO_EuroLLVM2015.pdf" class="">http://llvm.org/devmtg/2015-04/slides/ThinLTO_EuroLLVM2015.pdf</a>, however, ThinLTO seems to be much lower overhead than LTO. Are these results still accurate?)</div></div></div><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>We just published some updated results (including the new incremental mode):</div><div><br class=""></div><div><a href="http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html" class="">http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html</a></div><div><br class=""></div><div>— </div><div>Mehdi</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=""><div class="">5) What happens when the program-under-test is built from multiple source files? It seems that all source files must be compiled using the same export list, which is a burden on the tool user. Although this complexity could be managed by the program's build system, managing this complexity through the build system or by some other means still seems like a burden on the tool user.</div></div><div class=""><br class=""></div><div class=""><div class="">6) What happens when the program-under-test uses third-party libraries? If the tool user does not have access to the sources of those libraries, then I don't see how they can properly elide hooks using an export list. At best, it would seem that the library writer would distribute a object/bitcode for the library with all hooks in place already, which is exactly what happens with CSI's the existing design.</div><div class=""><br class=""></div><div class="">Thanks again for your feedback.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">TB</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jun 19, 2016 at 6:45 PM, Xinliang David Li <span dir="ltr" class=""><<a href="mailto:xinliangli@gmail.com" target="_blank" class="">xinliangli@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is great that CSI does not depend on lto for correctness, but I think it should remove the dependency completely. Being able to work with lto should be something that is supported, but lto is not required. <div class=""><br class=""></div><div class="">Such a design will greatly increase CSI usability not only for tool users(app developers), but also for CSI tool developers. </div><div class=""><br class=""></div><div class="">My understanding is that it is not far to get there. Here is the CSI use model I am thinking:</div><div class=""><br class=""></div><div class="">1) a CSI dev tool can be provided to tool developers to produce a) hook library in native object format b) hook lib in bitcode format c) export list of non stub hook defs</div><div class=""><br class=""></div><div class="">2) the compiler implementation of CSI lowering will check the export list and decide whether to lower a hook call to noop or not</div><div class=""><br class=""></div><div class="">3) in thinlto mode, the bitcode can be readin for inlining. This works for lto too</div><div class=""><br class=""></div><div class="">4) compiler driver can hide all the above from the users</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In short, making it work in default mode makes it easier to deploy and can get you a long way</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">David<div class=""><div class="h5"><span class=""></span><br class=""><br class="">On Sunday, June 19, 2016, TB Schardl <<a href="mailto:neboat@mit.edu" target="_blank" class="">neboat@mit.edu</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Hey Peter and David,</div><div class=""><br class=""></div><div class="">Thank you for your comments.<br class=""></div><div class=""><br class=""></div><div class=""><div style="font-size:12.8px" class="">As mentioned elsewhere, the current design of CSI does not rely on LTO for correctness. The tool-instrumented executable will run correctly even if the linker performs no optimization. In particular, unused instrumentation hooks are implemented by default as nop functions, which just return immediately. CSI is a system that <i class="">can use</i> LTO to improve tool performance; it does not <i class="">require </i>LTO to function.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">One of our considerations when developing CSI version 1 was design simplicity. As such, CSI version 1 essentially consists of three components:</div><div style="font-size:12.8px" class="">1) A compile-time pass that the tool user runs to insert instrumentation hooks.</div><div style="font-size:12.8px" class="">2) A null-tool library that provides default nop implementations for each instrumentation hook. When a tool writer implements a tool using the CSI API, the tool writer's implemented hooks override the corresponding default implementations.</div><div style="font-size:12.8px" class="">3) A runtime library that implements certain powerful features of CSI, including contiguous sets of ID's for hooks.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">We've been thinking about how CSI might work with -mlink-bitcode-file. From our admittedly limited understanding of that feature, it seems that a design that uses -mlink-bitcode-file would still require something like the first and third components of the existing design. Additional complexity might be needed to get CSI to work with -mlink-bitcode-file, but these two components seem to be core to CSI, regardless of whether -mlink-bitcode-file is used. (Eliminating the null-tool library amounts to eliminating a pretty simple 39-line C file, which at first blush doesn't look like a big win in design complexity).</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">CSI focuses on making it easy for tool writers to create many dynamic-analysis tools. CSI can leverage standard compiler optimizations to improve tool performance, if the tool user employs mechanisms such as LTO or thinLTO, but LTO itself is not mandatory. It might be worthwhile to explore other approaches with different trade-offs, such as -mlink-bitcode-file, but the existing design doesn't preclude these approaches down the road, and they will be able to share the same infrastructure. Unless the other approaches are dramatically simpler, the existing design seems like a good place to start.</div><div style="font-size:12.8px" class=""><br class=""></div></div><div style="font-size:12.8px" class="">Cheers,</div><div style="font-size:12.8px" class="">TB</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 17, 2016 at 4:25 PM, Peter Collingbourne via llvm-dev <span dir="ltr" class=""><<a class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="">On Thu, Jun 16, 2016 at 10:16 PM, Xinliang David Li via llvm-dev <span dir="ltr" class=""><<a class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="">On Thu, Jun 16, 2016 at 3:27 PM, Mehdi Amini via llvm-dev <span dir="ltr" class=""><<a class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi TB,<div class=""><br class=""></div><div class="">Thanks for you answer.</div><div class=""><br class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 2:50 PM, TB Schardl <<a class="">neboat@mit.edu</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Hey Mehdi,<div class=""><br class=""></div><div class="">Thank you for your comments. I've CC'd the CSI mailing list with your comments and put my responses inline. Please let me know any other questions you have.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">TB<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 16, 2016 at 3:48 PM, Mehdi Amini<span class=""> </span><span dir="ltr" class=""><<a class="">mehdi.amini@apple.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 9:01 AM, TB Schardl via llvm-dev <<a class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><span 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="">Hey LLVM-dev,</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=""><br class=""></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="">We propose to build the CSI framework to provide a comprehensive suite of compiler-inserted instrumentation hooks that dynamic-analysis tools can use to observe and investigate program runtime behavior. Traditionally, tools based on compiler instrumentation would each separately modify the compiler to insert their own instrumentation. In contrast, CSI inserts a standard collection of instrumentation hooks into the program-under-test. Each CSI-tool is implemented as a library that defines relevant hooks, and the remaining hooks are "nulled" out and elided during link-time optimization (LTO), resulting in instrumented runtimes on par with custom instrumentation. CSI allows many compiler-based tools to be written as simple libraries without modifying the compiler, greatly lowering the bar for</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="">developing dynamic-analysis tools.</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="">================</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="">Motivation</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="">================</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="">Key to understanding and improving the behavior of any system is visibility -- the ability to know what is going on inside the system. Various dynamic-analysis tools, such as race detectors, memory checkers, cache simulators, call-graph generators, code-coverage analyzers, and performance profilers, rely on compiler instrumentation to gain visibility into the program behaviors during execution. With this approach, the tool writer modifies the compiler to insert instrumentation code into the program-under-test so that it can execute behind the scene while the program-under-test runs. This approach, however, means that the development of new tools requires compiler work, which many potential tool writers are ill equipped to do, and thus raises the bar for building new and innovative tools.</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="">The goal of the CSI framework is to provide comprehensive static instrumentation through the compiler, in order to simplify the task of building efficient and effective platform-independent tools. The CSI framework allows the tool writer to easily develop analysis tools that require</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="">compiler instrumentation without needing to understand the compiler internals or modifying the compiler, which greatly lowers the bar for developing dynamic-analysis tools.</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="">================</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="">Approach</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="">================</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="">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></blockquote><div class=""><br class=""></div></span><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></div></div></blockquote><div class=""><br class=""></div><div class="">Here's the idea. When a tool user, who has a program they want to instrument, compiles their program source into an object/bitcode, he can turn on the CSI compile-time pass to insert instrumentation hooks (function calls to instrumentation routines) throughout the IR of the program. Separately, a tool writer implements a particular tool by writing a library that defines the subset of instrumentation hooks she cares about. At link time, the object/bitcode of the program source is linked with the object file/bitcode of the tool, resulting in a tool-instrumented executable. When LTO is used at link time, unused instrumentation is elided, and additional optimizations can run on the instrumented program. (I'm happy to send you a nice picture that we have of this flow, if the mailing list doesn't mind.)</div></div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Ok this is roughly what I had in mind.</div><div class=""><br class=""></div><div class="">I still believe it is not great to rely on LTO, and better, it is not needed to achieve this result.</div><div class=""><br class=""></div><div class="">For instance, I don't see why the "library" that defines the subset of instrumentation hooks used by this tool can't be fed during a regular compile, and the useless hook be eliminated at this point. </div><div class="">Implementation detail, but in practice, instead of feeding the library itself, the "framework" that allows to generate the library for the tool writer can output a "configuration file" along side the library, and this configuration file is what is fed to the compiler and tells the instrumentation pass which of the hooks to generate. It sounds more efficient to me, and remove the dependency on LTO. </div><div class="">I imagine there is a possible drawback that I'm missing right now...</div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div></div></div><div class="">I agree that the tool does not need to depend on full LTO. What is needed is essentially an option or configuration such that the compiler can find the bit code file(s) for the hooks during compilation time. It is pretty much similar to how math function inlining can be done ...</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">I agree, and I would strongly prefer that the design worked like this rather than relying on LTO.</div><div class=""><br class=""></div><div class="">The flag for loading bitcode already exists, and is called -mlink-bitcode-file. Projects such as libclc already use it, I believe.</div><div class=""><br class=""></div><div class="">What might be useful is if CSI improved the infrastructure around -mlink-bitcode-file to make it more convenient to produce compatible bitcode files. libclc for example relies on a post-processing pass to change symbol linkage, and I think that can be avoided by changing symbol linkages as they are imported from the bitcode file.</div><div class=""><br class=""></div><div class="">Peter</div><div class=""><div class=""><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="gmail_extra"><div class="gmail_quote"><div class="">David</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">The final binary is specialized to a given tool. One advantage of CSI, however, is that a single set of instrumentation covers the needs of a wide variety of tools, since different tools provide different implementations of the same hooks. The specialization of a binary to a given tool happens at link time.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span 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="">instrumented program-under-test is run. Furthermore, LTO can optimize a tool's instrumentation within a program using traditional compiler optimizations. Our initial study indicates that the use of LTO does not unduly slow down the build time</span></div></span></div></div></blockquote><div class=""><br class=""></div></span><div class="">This is a false claim: LTO has a very large overhead, and especially is not parallel, so the more core you have the more the difference will be. We frequently observes builds that are 3 times slower. Moreover, LTO is not incremental friendly and during debug (which is very relevant with sanitizer) rebuilding involves waiting for the full link to occur again.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div></font></span></div></div></blockquote><div class=""><br class=""></div><div class="">Can you please point us towards some projects where LTO incurs a 3x slowdown? We're interested in the overhead of LTO on build times, and although we've found LTO to incur more overhead on parallel build times than serial build times, as you mentioned, the overheads we've measured on serial or parallel builds have been less than 40% (which we saw when building the Apache HTTP server).</div></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I expect this to be reproducible on most non-trivial C/C++ programs.</div><div class="">But taking clang as an example, just running `ninja clang` on OS X a not-so-recent 12-cores machine takes 970s with LTO and 252s without (and I believe this is without debug info...).</div><div class="">Running just `ninja` to build all of llvm/clang here would take *a lot* longer with LTO, and not so much without.</div><div class=""><br class=""></div><div class="">The LTO builds without assert</div><div class=""><br class=""></div><div class="">Best,</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div></font></span><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">We've also designed CSI such that it does not depend on LTO for correctness; the program and tool will work correctly with ordinary ld. Of course, the downside of not using LTO is that instrumentation is not optimized, and in particular, unused instrumentation will incur overhead.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><font color="#888888" class=""><div class=""></div><div class=""><br class=""></div>-- </font></span></div><span class=""><font color="#888888" class=""><div class="">Mehdi</div></font></span><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span 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="">, and the LTO can indeed optimize away unused hooks. One of our experiments with Apache HTTP server shows that, compiling with CSI and linking with the "null" CSI-tool (which consists solely of empty hooks) slows down the build time of the Apache HTTP server by less than 40%, and the resulting tool-instrumented executable is as fast as the original uninstrumented code.</span></div></span></div></div></blockquote></span><blockquote type="cite" class=""><div class=""><span 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="">================</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="">CSI version 1</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="">================</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="">The initial version of CSI supports a basic set of hooks that covers the following categories of program objects: functions, function exits (specifically, returns), basic blocks, call sites, loads, and stores. We prioritized instrumenting these IR objects based on the need of seven example CSI tools, including a race detector, a cache-reuse analyzer, and a code-coverage analyzer. We plan to evolve the CSI API over time to be more comprehensive, and we have designed the CSI API to be extensible, allowing new instrumentation to be added as needs grow. We chose to initially implement a minimal "core" set of hooks, because we felt it was best to add new instrumentation on an as-needed basis in order to keep the interface simple.</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="">There are three salient features about the design of CSI. First, CSI assigns each instrumented program object a unique integer identifier within one of the (currently) six program-object categories. Within each category, the ID's are consecutively numbered from 0 up to the number of such objects minus 1. The contiguous assignment of the ID's allows the tool writer to easily keep track of IR objects in the program and iterate through all objects in a category (whether the object is encountered during execution or not). Second, CSI provides a platform-independent means to relate a given program object to locations in the source code. Specifically, CSI provides "front-end-data (FED)" tables, which provide file name and source lines for each program object given the object's ID. Third, each CSI hook takes in as a parameter a "property": a 64-bit unsigned integer that CSI uses to export the results of compiler analyses and other information known at compile time. The use of properties allow the tool to rely on compiler analyses to optimize instrumentation and decrease overhead. In particular, since the value of a property is known at compile time, LTO can constant-fold the conditional test around a property to elide unnecessary instrumentation.</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="">================</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="">Future plan</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="">================</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="">We plan to expand CSI in future versions by instrumenting additional program objects, such as atomic instructions, floating-point instructions, and exceptions. We are also planning to provide additional static information to tool writers, both through information encoded in the properties passed to hooks and by other means. In particular, we are also looking at mechanisms to present tool writers with more complex static information, such as how different program objects relate to each other, e.g., which basic blocks belong to a given function.</span></div><div class=""><span style="font-size:14.6667px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent" class=""><br class=""></span></div></span></div></span><span class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></span></div><br class=""></div></div><br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a 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></div></div><br class=""></div></div>
<br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a 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></div></div><span class=""><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div data-smartmail="gmail_signature" class=""><div dir="ltr" class="">-- <div class="">Peter</div></div></div>
</font></span></div></div>
<br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a 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></div></div>
</blockquote></div><br class=""></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>