llvm dev - Feb 2013 - [LLVMdev] How to measure the overhead of instrumented code

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?

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

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>

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of John Criswell
> Subject: Re: [LLVMdev] How to measure the overhead of instrumented code
> > 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).
> If you know the length of your instrumentation in bytes, you could generate
> inline assembly code that inserts the correct number of NOP instructions.
Except that current Intel CPUs include a micro-op cache, where the NOPs pretty
much disappear; this is no longer a simple problem.  VTune or PAPI are your best
bet.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.