Re: [PATCH] LLVM tuple deforming improvements

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(dot)psql(at)pinaraf(dot)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