Horton

Re: JIT compiling with LLVM v9.0

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

View thread View on postgr.es
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-01-29T12:45:56Z
Lists: pgsql-hackers

Attachments


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

Commits

  1. Improve JIT docs.

  2. Add documentation for the JIT feature.

  3. Add EXPLAIN support for JIT.

  4. Add inlining support to LLVM JIT provider.

  5. JIT tuple deforming in LLVM JIT provider.

  6. Add FIELDNO_* macro designating offset into structs required for JIT.

  7. Add expression compilation support to LLVM JIT provider.

  8. Expand list of synchronized types and functions in LLVM JIT provider.

  9. Add helpers for emitting LLVM IR.

  10. Basic planner and executor integration for JIT.

  11. Debugging and profiling support for LLVM JIT provider.

  12. Support for optimizing and emitting code in LLVM JIT provider.

  13. Add file containing extensions of the LLVM C API.

  14. Basic JIT provider and error handling infrastructure.

  15. Add configure infrastructure (--with-llvm) to enable LLVM support.

  16. Add C++ support to configure.

  17. Add PGAC_PROG_VARCC_VARFLAGS_OPT autoconf macro.

  18. Fix VM buffer pin management in heap_lock_updated_tuple_rec().

  19. Allow tupleslots to have a fixed tupledesc, use in executor nodes.

  20. Expression evaluation based aggregate transition invocation.

  21. Perform slot validity checks in a separate pass over expression.

  22. Rely on executor utils to build targetlist for DML RETURNING.

  23. Refer to OS X as "macOS", except for the port name which is still "darwin".