[llvm-dev] Higher level program analysis

[David Greene via llvm-dev]

preejackie via llvm-dev <llvm-dev at lists.llvm.org> writes:

> Are you suggesting that static analysis is much inferior than
> profiling in finding "next executing function" ?  I'm stuck at
> deciding which one to prefer & implement during this summer project,
> Could you please help me?

I suspect this is highly code-dependent.  For example, it's probably
feasible to use static analysis to determine error paths, at least for
fairly well-behaved programs.  A whole-program analysis might be able to
better determine such paths but that's likely too heavyweight for a JIT.
AOT could do it and use metadata to guide the JIT.

On some codes, paths within a loop may be fairly evenly distributed over
iterations while for others, execution may be highly biased toward a
few.  This is probably going to be the most difficult thing to analyze
statically without a lot of context and even then it may be determined
by runtime user input and therefore unknowable statically.

> Also if I choose to do PGO stuff with ORC, Can I able to use most of
> PGO code available for AOT with the JIT. Is there any downsides to it?

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.

                          -David