[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

> 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 

> 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!


More information about the llvm-dev mailing list