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