[llvm-dev] GSoC- Speculative compilation support in ORC v2 , looking for mentors!

[preejackie via llvm-dev]

Hi all,

I would like to propose "Speculative compilation support in ORC v2 JIT 
API" for this year GSoC summer project.

Project Description:

Speculative compilation support. One of the selling points of the 
concurrent ORC APIs is that you can start compiling a function before 
you need it, in the hope that by the time that you do need it it is 
already compiled. However, if we just speculatively compile everything 
we're quickly going to overload our memory/CPU resources, which will be 
lousy for performance. What we really want to do is to take into account 
any information we have (from high level program representations, e.g. 
ASTs or CFGs, or from profiling data from previous executions) to try to 
guess what functions are worth speculatively compiling next.

Idea is proposed by Lang Hames.

Current Status of ORC v2:


 1.

    ORC currently supports concurrent compilation and Lazy (on request
    compilation), trunk contains default new ORC JIT implementations as
    LLJIT, LLLazyJIT.

 2.

    [WIP]  Jit-linker a drop-in-replacement for RuntimeDyld atleast for
    MachO in ORC JIT.

 3.

    Primitive code to handle speculative is in trunk. But it needs to
    refactored & designed to get generalized, simple APIs to support
    speculation.

 4.

    Currently, no heuristics to support speculation in trunk.


Proposed Solution:

 1.

    New APIs in ORC v2 to support speculation compilation of LLVM
    bitcode. LLSpecJIT - subtype of LLJIT, default JIT with speculation
    support in trunk.

 2.

    Heuristics to guide speculation -

Currently, I’m going through some literature/research papers to find 
good basic heuristics. We can derive useful information from Control 
flow graphs, IR etc. So far I figured out that Region-based compilation 
is more appropriate for speculation. Since, unit of compilation 
(granularity) is key good dynamic compilation, region based compilation 
address that by forming frequently executed code as a region (unit), 
this can be basic block, function or group of functions. But since, LLVM 
JIT API needs interoperates with static compiler, unit of compilation 
here is a complete module. The plan in mind is to break the module into 
regions and compile regions speculatively using multiple JIT backend 
light weight threads. I’m still not sure, how this can be done, I would 
highly appreciate the feedback from community in deciding the heuristics 
& granularity to compile.

3.Practical example with benchmarks: To my best of knowledge PostgreSQL 
using ORC API, it would be easier to get postgresql queries to get 
compile speculatively and compare results with baseline (concurrent 
compiler without speculation).

4. Unit tests + documentation.


Benefits:

 1.

    We can full use of multiple compilation threads, to compile code
    upfront with minimum false positive.

 2.

    Stabilize JIT APIs which most clients looking for when transitioning
    to newer versions.


Further Opportunities :

We can also use thinlto summaries in module to decide which code is 
worthier to compile next, based on this lighting LLVM Dev talk by Stefan 
<https://www.youtube.com/watch?v=ZCnHxRhQmvs>.

Profile guided optimization - information will be helpful in this, 
provide further room for improvement.

I would highly appreciate the community feedback & suggestions :)

I will try my best to address all the comments in the proposal. I'm 
currently familiarizing myself with new APIs and learning heuristics. I 
will try to get the draft proposal by next week.

References: HHVM JIT: A profile-Guided, Region-Based Compiler for PHP & 
Hack [paper <https://dl.acm.org/citation.cfm?id=3192374>].

PostgreSQL [JIT <https://doxygen.postgresql.org/structLLVMJitHandle.html>]

Execution Engine [ORC 
<https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/lib/ExecutionEngine/Orc/>] 


-- Have a great day! PreeJackie

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