[LLVMdev] Path profiling interface proposal
David Greene
dag at cray.com
Mon Jul 13 09:43:50 PDT 2009
On Saturday 11 July 2009 00:26, Slobodan Pejic wrote:
> This section was included because running edge profiling from c sources
> to the final executable threw me off when I was familiarizing myself
> with LLVM. The edge instrumentor can only instrument modules with a
> main function, so any modules that one wants instrumented must be linked
> to the module with main first. My Instrumetor is similar in structure.
Ooh, that's a nasty restriction. Is it inherent to the algorithm or
just the implementation? To be generally useful we need to remove this
restriction.
> Yes, libprofile_rt already exists, however it must be built by invoking
> make in runtime/.
Ok, that's no problem.
> The function is supposed to allow the compiler developer to find the
> subset of paths that contain certain basic blocks. E.g. consider this CFG:
Ah, ok, that makes sense. The comments should say something about this.
> > I also don't understand the "order" parameter. How are paths ordered?
> > By number? Why does the returned order of paths matter?
>
> The idea is to load as little as possible from the on-disk profile if
> the entire profile is not required. In order to delay loading the
> profile (which may have been sorted by count in the runtime library
> saving the profile), the iterator over paths can load the data lazily.
> Some potential passes may want to look at the top paths that account for
> 80% execution, and will not require the majority of the path profile.
How large are the profile files, generally? I'd imagine they can get pretty
huge. Lazy loading is a good idea. Perhaps the comments can explain this
a bit more and provide the various values defined for "order" and their
meaning.
> Your assumption is correct. This function can be renamed to
> getFrequencyPerFunction().
I'm not sure that's any clearer. Unfortunately, I can't think of anything
better at the moment. In any case, the comments should explain what it is.
Thanks for your work on this!
-Dave
More information about the llvm-dev
mailing list