Hi, On 2019-04-02 00:51:51 +0530, preejackie wrote: > As LLVM ORC supports compiling in multiple backend threads, it would be > effective if we compile the functions speculatively before they are called > by the executing function. So when we request JIT to compile a function, JIT > will immediately returns the function address for raw executable bits. This > will greatly reduce the JIT latencies in modern multi-core machines. I personally think this should be approached somewhat differently - putting patchpoints into code reduces the efficiency of the generated code, so I don't think that's the right approach. What I think we should do is to, if we decide it's worthwhile at plan time, generate the LLVM IR time at the beginning of execution, but continue to use interpreted execution initially. The generated IR would then be handed over to a background [process|thread|whatnot] for optimization of code generation. Then, when finished, I'd switch over from interpreted to JIT compiled execution. That approach will, in my view, yield better latency behaviour because we can actually evaluate quals etc for which we've not yet finished code generation. > And also I'm working on designing a ORC in-place dynamic profiling support, by > this JIT will automatically able to identify the hot functions, and compile > it in higher optimization level to achieve good performance. I think that's a nice concept, but at the moment the generated code is so bad that it's much more likely to get big benefits by improving the generated IR, compared to giving more hints to the optimizer. Greetings, Andres Freund
