Re: JIT compiling with LLVM v9.0

On 26.01.2018 22:38, Andres Freund wrote:
> And without it perf is not able to unwind stack trace for generated
>> code.
> You can work around that by using --call-graph lbr with a sufficiently
> new perf. That'll not know function names et al, but at least the parent
> will be associated correctly.

With --call-graph lbr result is ... slightly different (see attached 
profile) but still there is "unknown" bar.

>> But you are compiling code using LLVMOrcAddEagerlyCompiledIR
>> and I find no way to pass no-omit-frame pointer option here.
> It shouldn't be too hard to open code support for it, encapsulated in a
> function:
>      // Set function attribute "no-frame-pointer-elim" based on
>      // NoFramePointerElim.
>      for (auto &F : *Mod) {
>        auto Attrs = F.getAttributes();
>        StringRef Value(options.NoFramePointerElim ? "true" : "false");
>        Attrs = Attrs.addAttribute(F.getContext(), AttributeList::FunctionIndex,
>                                   "no-frame-pointer-elim", Value);
>        F.setAttributes(Attrs);
>      }
> that's all that option did for mcjit.

I have implemented the following function:

void
llvm_no_frame_pointer_elimination(LLVMModuleRef mod)
{
     llvm::Module *module = llvm::unwrap(mod);
     for (auto &F : *module) {
         auto Attrs = F.getAttributes();
         Attrs = Attrs.addAttribute(F.getContext(), 
llvm::AttributeList::FunctionIndex,
                                    "no-frame-pointer-elim", "true");
         F.setAttributes(Attrs);
     }
}

and call it before LLVMOrcAddEagerlyCompiledIR in llvm_compile_module:

         llvm_no_frame_pointer_elimination(context->module);
         smod = LLVMOrcMakeSharedModule(context->module);

         if (LLVMOrcAddEagerlyCompiledIR(compile_orc, &orc_handle, smod,
                                         llvm_resolve_symbol, NULL))
         {
             elog(ERROR, "failed to jit module");
         }


... but it has no effect: produced profile is the same (with 
--call-graph dwarf).
May be you can point me on my mistake...


Actually I am trying to find answer for the question why your version of 
JIT provides ~2 times speedup at Q1, while ISPRAS version 

(https://www.pgcon.org/2017/schedule/attachments/467_PGCon%202017-05-26%2015-00%20ISPRAS%20Dynamic%20Compilation%20of%20SQL%20Queries%20in%20PostgreSQL%20Using%20LLVM%20JIT.pdf)
speedup Q1 is 5.5x times.
May be it is because them are using double type to calculate aggregates 
while as far as I understand you are using standard Postgres aggregate 
functions?
Or may be because ISPRAS version is not checking for NULL values...

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company