[llvm-dev] Higher level program analysis

[David Greene via llvm-dev]

preejackie <praveenvelliengiri at gmail.com> writes:

> > I'm sorry I can't really comment on that as I don't have much
> > experience with it.  From what little I've looked at the
> > instrumentation code, it seems fairly standard, in that it tries to
> > limit the profiling overhead using minimum spanning tree techniques.
> > Whether that is too heavyweight for a JIT I can't really say.  I
> > suspect it would potentially severely impact performance for some
> > codes.  Of course, once a path has been determined to be hot you'd
> > probably want to remove the instrumentation.
>
> Idea here is not only to recompile hot functions but also compiling
> them ahead of time before they actually start to execute. So I hope
> that it will not be heavy weight for JIT, given that we ruled out the
> static analysis approach. It would be nice to reuse many parts of
> static PGO stuff here, and I will implement to profile, data which is
> only useful in case of JIT.

My concern would be with the overhead of the instrumentation in loops.
If the common path within the loop body is unknown, instrumentation to
determine it might slow down the loop considerably.  A sampling approach
might be preferred in some cases.

I'm really excited for this work though!  I think we'll learn a lot
about the PGO infrastructure by trying to apply it dynamically.

                        -David