Hi all,
I need to do dynamic profiling in ORC JIT between the runs. Is it possible to re-use parts of the static pgo code in llvm for the purpose given that JIT uses llvm codegen. Or I need to write my own implementation to support profile guide optimization in JIT ?
Please tell me if you want information.
Currently PGO is based on branch weight metadata, indirect call target meta data, function entry counts, and profile summary. It is independent of source of profile data, so most of the support is already there if the dynamic profiling provides the same/subset of information. However If you have new types of profile data that no existing PGO passes take advantage of, you can certainly need to write your own support for that.
David
Hi David,
Thanks for your reply. I find that I need to add some new types of profile data that are specific to JIT environment like Function Ordering. Function Ordering is similar to dynamic call graph which records the execution of functions at runtime along with the order in which they are called.
Eg: Suppose they are 5 functions (F1…F5). F1 calls other functions in the order described below, count tells how many times that function is called from F1.
Start[1] → F1 → F2 [1]
→ F4 [1]
→ F2 [2]
→ F1 [0] (recursions)
→ F5 [1].
This shows us which function is likely going to execute next. So with the help of multiple JIT background threads, those functions get compiled before they are referenced. This will help in reducing JIT compilation latencies in multi-core machines. This order must be collected during profiling so that we can use in JIT.
I’m new to PGO, I don’t know how the internals details much. As I’m proposing this project for GSoC’19, i would like to learn how PGO is structured, it will help to design similar for JIT & write a proposal. I googled but is less information available about the internals. Is any references to internals/working of PGO are welcome!
Hi David,
Thanks for your reply. I find that I need to add some new types of profile data that are specific to JIT environment like Function Ordering. Function Ordering is similar to dynamic call graph which records the execution of functions at runtime along with the order in which they are called.
Eg: Suppose they are 5 functions (F1..F5). F1 calls other functions in the order described below, count tells how many times that function is called from F1.
Start[1] --> F1 --> F2 [1]
--> F4 [1]
--> F2 [2]
--> F1 [0] (recursions)
--> F5 [1].
This shows us which function is likely going to execute next. So with the help of multiple JIT background threads, those functions get compiled before they are referenced. This will help in reducing JIT compilation latencies in multi-core machines. This order must be collected during profiling so that we can use in JIT.
With AOT compilation, the function layout is usually done by linker
plugin or LTO. JIT sees whole program and can certainly do function
layout with profile data.
I'm new to PGO, I don't know how the internals details much. As I'm proposing this project for GSoC'19, i would like to learn how PGO is structured, it will help to design similar for JIT & write a proposal. I googled but is less information available about the internals. Is any references to internals/working of PGO are welcome!
PGO includes 'profile driven' optimizations and 'profile aware'
optimizations. Profile aware optimizations spread across many
optimization passes and there is currently no central place for
documentation. Here are a list of optimizations (but not limited to)
that are profile aware: inliner (including thinLTO function importing)
block layout, register allocator, unroller, loop peeling, loop
sinking, vectorization etc. Others such as speculative PRE can also
make use of profile info. Profile driven size optimization is also
under development.
'profile driven' optimizations include value profiling transformations
such as indirect call promotion, memcpy/set specialization, control
height reduction, function layout etc.
Another big chunk of PGO is the PGO infrastructure: including profile
reader/writer, instrumentation, lowering, profile loader/summary
analysis, profiling runtime, profile merging tool etc. PMU based
samplePGO adds another dimension to it.
David
Hi David,
Thanks a lot forthe detailed information, but re-using static PGO stuff in the context of JIT is pretty challenging. I’m working on that, I’m also thinking about adding a new intrinsic, but it makes sense only in the context of JIT. The challenge here is how we can create profdata during the execution of instrumented binary from JIT. In AOT compiler execution of instrumented binary produce a profdata file, how produce this one in JIT is still open question for me.
The interface to PGO passes are MD_prof meta data. The optimizations don’t really care about persistent profile format or the existence of it. JIT profiler can maintain in-memory profile counters and update the IR when ready.
David