Re: JIT compiling with LLVM v9.0

Hi,

On 2018-01-27 16:56:17 -0800, Jeff Davis wrote:
> 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?

Yea, I'd planned and started to do so. I actually hope we can get more
committed than just the tuple deforming code - for one it currently
integrates directly with the expression evaluation code, and my
experience with trying to do so outside of it have not gone well.

> 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?

I think basically the later a patch currently is in the series the less
important it is.

I've already committed a lot of preparatory patches (like that aggs now
use the expression engine), and I plan to continue doing so.

> 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:

I'm very strongly against this. To the point that I'll not pursue JITing
further if that becomes a requirement.

I could be persuaded to put it into a shared library instead of the main
binary itself, but I think developing it outside of core is entirely
infeasible because quite freuquently both non-JITed code and JITed code
need adjustments. That'd solve your concern about

> * Would mean postgres itself isn't dependent on a huge library like
> llvm, which just seems like a good idea from a packaging standpoint.

to some degree.

I think it's a fools errand to try to keep in sync with core changes on
the expression evaluation and struct definition side of things. There's
planner integration, error handling integration and similar related
things too, all of which require core changes. Therefore I don't think
there's a reasonable chance of success of doing this outside of core
postgres.

> 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 heaptuple.c stuff could largely be dropped, that was more an effort
to level the plainfield a bit to make the comparison fairer. I kinda
wondered about putting the JIT code in a heaptuple_jit.c file instead of
heaptuple.c.

> 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.

Well, but doing this outside of core would pretty much prohibit doing so
forever, no? Getting the inlining design right has influenced several
other parts of the code. I think it's right that the inlining doesn't
necessarily have to be part of the initial set of commits (and I plan to
separate it out in the next revision), but I do think it has to be
written in a reasonably ready form at the time of commit.

Greetings,

Andres Freund