[llvm-dev] Higher level program analysis

[preejackie via llvm-dev]

Hi David,

Thanks for the reply :) Please see my comments inline.

On 30/03/19 3:08 AM, David Greene wrote:
> 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.
Agreed, such kind of analysis requires more time which will directly 
impacts the execution time of Application in JIT. Even though PGO has 
extra build/instrument/run cycle I think it will generate good 
representatives of real time workload. So I decided to implement dynamic 
profile (instrumentation) for JIT.
>> 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.
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.
>                            -David

-- 
Have a great day!
PreeJackie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190330/fe9ea693/attachment.html>