Re: JIT compiling with LLVM v9.0

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: JIT compiling with LLVM v9.0
Date: 2018-01-29 12:45:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:

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(),
                                   "no-frame-pointer-elim", "true");

and call it before LLVMOrcAddEagerlyCompiledIR in llvm_compile_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
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
Or may be because ISPRAS version is not checking for NULL values...

Konstantin Knizhnik
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
q1.svg image/svg+xml 42.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2018-01-29 12:47:41 Re: A Generic Question about Generic type subscripting
Previous Message Fabien COELHO 2018-01-29 12:03:16 Re: General purpose hashing func in pgbench