Re: Instrumenting code for profiling.

diablovision@yahoo.com (Ben L. Titzer)
20 Nov 2004 21:24:23 -0500

          From comp.compilers

Related articles
Instrumenting code for profiling. par_ianth@yahoo.com (2004-11-14)
Re: Instrumenting code for profiling. gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-11-17)
Re: Instrumenting code for profiling. s.bosscher@student.tudelft.nl (2004-11-17)
Re: Instrumenting code for profiling. nmm1@cus.cam.ac.uk (2004-11-19)
Re: Instrumenting code for profiling. diablovision@yahoo.com (2004-11-20)
Re: Instrumenting code for profiling. idbaxter@semdesigns.com (Ira Baxter) (2004-11-20)
Re: Instrumenting code for profiling. tmk@netvision.net.il (2004-11-20)
Re: Instrumenting code for profiling. nmm1@cus.cam.ac.uk (2004-11-26)
| List of all articles for this month |

From: diablovision@yahoo.com (Ben L. Titzer)
Newsgroups: comp.compilers
Date: 20 Nov 2004 21:24:23 -0500
Organization: http://groups.google.com
References: 04-11-043
Keywords: performance, debug
Posted-Date: 20 Nov 2004 21:24:23 EST

par_ianth@yahoo.com (PK) wrote
> I had a question regarding how compilers do instrumentation to
> collect profile information. Specifically, how do compilers handle the
> part of mapping the collected profile back to the original program
> (which is without the instrumentation).
>
> Say a program X is instrumented with profiling calls for gathering
> branch execution frequency. If I use the virtual address of the branch
> instruction as the index or key against which I collect the frequency
> of that branch, then I have a problem since the virtual address would
> be completely different in the instrumented version and in the
> non-instrumented version. So how do I maintain this mapping between
> the profile data that I collect and the actual instruction in the
> program? I think I need some sort of 'unique' id for each branch in
> the original program. Could someone give me some pointers about how
> this is done in the commercial compilers?


One thing that you can do, depending on the situation, is to run the
program inside an instruction-level simulator that is capable of
gathering the profiling information that you want. For example, a
simulator might collect an execution count for each instruction, a
branch direction count, etc. You can then use this information and the
mapping back to the source program to get source frequency
information.


Depending on how accurate the simulation is (for example, the
simulator may not mimic the real processor's pipeline), you can get
more or less accurate results.


In my work, I have written a simulator for an embedded architecture
that fully simulates the behavior of the hardware at the clock cycle
level. It then allows "probes" to be inserted at various instructions,
and the probes "fire" when that instruction executes. Thus the probe
can collect profiling information, branch frequency, enable other
probes, etc.


This is a good approach if you can get it--it doesn't require hacking
the program or the compiler.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.