[llvm-dev] GSoC Proposal : Path Profiling Support

[Vedant Kumar via llvm-dev]

Hi,

This sounds like a very interesting proposal!

> This proposal adds support  for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at runtime.

In [Ball96], the authors mention that the worst case number of acyclic
paths in a program is exponential in its size. How do you manage this? Is
the amount of instrumentation necessary to handle this scenario also
exponential in the size of the program? 


> Path profiles enable precise enumeration of the sequence of basic blocks executed in order for a particular path. Using path profiles has been demonstrated by [Young98] to perform better global scheduling than edge profiles.

I haven't had time to digest [Young98]. Could you explain in some more
detail which optimizations stand to benefit from path profile information?


> Over the last year, I have built a toolchain which uses path profiling as its basis.

Awesome!

Do you have any numbers about the size of path profiles, compared to the
size of raw instrprof-based profiles?

In general I'm curious about how we can support users of instrprof-style
profiles with path profiles. Do you have plans to support code coverage
using path profiles? Can path profiles from dylibs be concatenated together
to yield valid profiles?


> + Used to analyse C/C++ benchmarks from SPECCPU2006

I'd be interested to see any numbers you have about this. In particular,
what's the compile-time overhead of path profiling instrumentation? What
are the sizes of instrumented binaries, and what's the slowdown factor?


> Open Issues :
> + Update PathProfileInfo on CFG transformations ?

Could you clarify what this means?

> + Verify with PGOEdge info ?

Ditto.

> + Handle setjmp, longjmp, early program termination, noreturn calls

How do you handle indirect calls?

best,
vedant