[llvm-dev] RFC: Comprehensive Static Instrumentation

[Reid Kleckner via llvm-dev]

Mehdi, I think TB is saying that LTO is actually *more* incremental than
standard compilation for people writing instrumentation tools.

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.

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.

On Fri, Jun 17, 2016 at 11:42 AM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
>
> It is a very artificial advantage, what are you saving? Temporary Disk
> Space?
>
>
> 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
>
>
> These results suggests that “adding instrumentation has a cost” nothing
> more, and is unrelated to LTO at all.
> You would provide the runtime to the compiler directly during the compile
> phase and you would get the same results.
>
>
> , which would allow tool users to only compile their sources once.
>
>
> LTO means basically “compiles during the link”. You won’t save much.
>
> I haven’t seen a single compelling argument to *tie* CSI to LTO in this
> thread until now.
>
>
> —
> Mehdi
>
>
>
>
>
>
>
>>
>> It's possible that the math doesn't really work out in practice if the
>> cost of the LTO-link dwarfs the compile times.
>>
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160617/92d784f6/attachment.html>