On Friday, July 13, 2018 11:08:45 PM CEST Andres Freund wrote: > Hi, > > Thanks for looking at this! > > On 2018-07-13 10:20:42 +0200, Pierre Ducroquet wrote: > > 2) improve the LLVM IR code > > > > The code generator in llvmjit-deform.c currently rely on the LLVM > > optimizer to do the right thing. For instance, it can generate a lot of > > empty blocks with only a jump. If we don't want to enable the LLVM > > optimizer for every code, we have to get rid of this kind of pattern. The > > attached patch does that. When the optimizer is not used, this gets a few > > cycles boost, nothing impressive. I have tried to go closer to the > > optimized bitcode, but it requires building phi nodes manually instead of > > using alloca, and this isn't enough to bring us to the performance level > > of -O1. > > Building phi blocks manually is too painful imo. But there's plenty > blocks we could easily skip entirely, even without creating phi nodes. > > > From 4da278ee49b91d34120747c6763c248ad52da7b7 Mon Sep 17 00:00:00 2001 > > From: Pierre Ducroquet <p.p...@pinaraf.info> > > Date: Mon, 2 Jul 2018 13:44:10 +0200 > > Subject: [PATCH] Introduce opt1 in LLVM/JIT, and force it with deforming > > I think I'd rather go for more explicit pipelines than defaulting to OX > pipelines. This is too late for v11, and I suspect quite strongly that > we'll end up not relying on any of the default pipelines going forward - > they're just not targeted at our usecase. I just didn't go there for > v11, because I was running out of steam / time.
Hi After looking at the optimization passes, I noticed that, at least in that case, most benefits do not come from any of the bitcode level passes. Using a -O3 pipeline only on the bitcode gives at best a 20% performance boost. Using a -O0 on the bitcode, but changing the codegen opt level from None (O1) to Less (O1) yields even better performance than a complete O1. The attached patch alone gives a query time of 650 ms, vs 725ms for 'full' O1 and 770ms for O3. As far as I know (and from quickly looking at LLVM code, it doesn't look like this changed recently), the CodeGen part doesn't expose a pass manager, thus making it impossible to have our own optimization pipeline there, and we do not control the code generation directly since we rely on the ORC execution engine. Regards Pierre
>From 8b66f60869e285b6f45f3cb900f8c1df44df15ee Mon Sep 17 00:00:00 2001 From: Pierre Ducroquet <p.p...@pinaraf.info> Date: Sat, 14 Jul 2018 01:51:31 +0200 Subject: [PATCH] LLVM - Use the O1 CodeGen level --- src/backend/jit/llvm/llvmjit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c index 5d0cdab1fc..a73619ae2f 100644 --- a/src/backend/jit/llvm/llvmjit.c +++ b/src/backend/jit/llvm/llvmjit.c @@ -643,7 +643,7 @@ llvm_session_initialize(void) llvm_opt0_targetmachine = LLVMCreateTargetMachine(llvm_targetref, llvm_triple, cpu, features, - LLVMCodeGenLevelNone, + LLVMCodeGenLevelDefault, LLVMRelocDefault, LLVMCodeModelJITDefault); llvm_opt3_targetmachine = -- 2.18.0
