[LLVMdev] How to measure the overhead of instrumented code

[John Criswell]

On 2/24/13 10:07 AM, Lu Mitnick wrote:
> Hello all,
>
> I have developed a instrumented pass which insert some variables 
> between the original variables,
> as well as insert some code into the original source code. just like:
>
> ============= original source code =============
>
> int a[10];
>
> void fun1 () {
>     // some  source code here
> }
>
> =========================================
>
> ============= instrumented source code =============
>
> int dummy1[20];
> int a[10];
> int dummy2[30];
>
> void fun1 () {
>     // instrumented source code 1
>     // some  source code here
>     // instrumented source code 2
> }
>
> ============= instrumented source code =============
>
> Apparently, dummy1 and dummy2 may cause pressure of data cache, and 
> instrumented source code 1
> and instrumented source code 2 may lead not only execution overhead 
> but also extra instruction cache
> pressure. Now I want to measure these separated overhead precisely. To 
> measure the pressure of
> instruction cache, I want to replace the instrumented source code as 
> nop (with length equals the length of
> instrumented source code). Is there anyway to instrument nop 
> explicitly in LLVM?

If you know the length of your instrumentation in bytes, you could 
generate inline assembly code that inserts the correct number of NOP 
instructions.

Alternatively, if your processor has the necessary performance counter 
registers, you could simply measure the change in cache performance 
between the instrumented and uninstrumented code.  For x86_64 
processors, you can use VTune (which will sample the performance counter 
registers) or you can use the perfctr Linux kernel patch and tools to 
get a precise measurement.

-- John T.

>
> Thanks
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130225/93450df2/attachment.html>