[llvm-dev] Higher level program analysis

[preejackie via llvm-dev]

On 03/04/19 7:38 PM, David Greene wrote:
> 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 working on Recording/Play back design for JIT. As this is a initial 
experiment, we have planned to defer using the static PGO infrastructure 
for JIT. The Main problem is getting ORC JIT to know about profile data 
and how to collect it dynamically.
> 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

-- 
Have a great day!
PreeJackie