Re: JIT compiling with LLVM v9.0

On Sat, Jan 27, 2018 at 1:20 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> b) The optimizations to take advantage of the constants and make the
> code faster with the constant tupledesc is fairly slow (you pretty
> much need at least an -O2 equivalent), whereas the handrolled tuple
> deforming is faster than the slot_getsomeattrs with just a single,
> pretty cheap, mem2reg pass. We're talking about ~1ms vs 70-100ms in
> a lot of cases. The optimizer often will not actually unroll the
> loop with many attributes despite that being beneficial.

This seems like the major point. We would have to customize the
optimization passes a lot and/or choose carefully which ones we apply.

> I think in most cases using the approach you advocate makes sense, to
> avoid duplication, but tuple deforming is such a major bottleneck that I
> think it's clearly worth doing it manually. Being able to use llvm with
> just a always-inline and a mem2reg pass makes it so much more widely
> applicable than doing the full inlining and optimization work.

OK.

On another topic, I'm trying to find a way we could break this patch
into smaller pieces. For instance, if we concentrate on tuple
deforming, maybe it would be committable in time for v11?

I see that you added some optimizations to the existing generic code.
Do those offer a measurable improvement, and if so, can you commit
those first to make the JIT stuff more readable?

Also, I'm sure you considered this, but I'd like to ask if we can try
harder make the JIT itself happen in an extension. It has some pretty
huge benefits:
* The JIT code is likely to go through a lot of changes, and it
would be nice if it wasn't tied to a yearly release cycle.
* Would mean postgres itself isn't dependent on a huge library like
llvm, which just seems like a good idea from a packaging standpoint.
* May give GCC or something else a chance to compete with it's own JIT.
* It may make it easier to get something in v11.

It appears reasonable to make the slot deforming and expression
evaluator parts an extension. execExpr.h only exports a couple new
functions; heaptuple.c has a lot of changes but they seem like they
could be separated (unless I'm missing something).

The biggest problem is that the inlining would be much harder to
separate out, because you are building the .bc files at build time. I
really like the idea of inlining, but it doesn't necessarily need to
be in the first commit.

Regards,
Jeff Davis