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 |
Message-ID: | a323c1f6-ccb7-f309-3b41-a9c1951e586b@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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:
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
Attachment | Content-Type | Size |
---|---|---|
q1.svg | image/svg+xml | 42.8 KB |
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 |