Horton

Re: JIT compiling with LLVM v9.0

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-01-28T01:15:42Z
Lists: pgsql-hackers 
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

Commits

  1. Improve JIT docs.

  2. Add documentation for the JIT feature.

  3. Add EXPLAIN support for JIT.

  4. Add inlining support to LLVM JIT provider.

  5. JIT tuple deforming in LLVM JIT provider.

  6. Add FIELDNO_* macro designating offset into structs required for JIT.

  7. Add expression compilation support to LLVM JIT provider.

  8. Expand list of synchronized types and functions in LLVM JIT provider.

  9. Add helpers for emitting LLVM IR.

  10. Basic planner and executor integration for JIT.

  11. Debugging and profiling support for LLVM JIT provider.

  12. Support for optimizing and emitting code in LLVM JIT provider.

  13. Add file containing extensions of the LLVM C API.

  14. Basic JIT provider and error handling infrastructure.

  15. Add configure infrastructure (--with-llvm) to enable LLVM support.

  16. Add C++ support to configure.

  17. Add PGAC_PROG_VARCC_VARFLAGS_OPT autoconf macro.

  18. Fix VM buffer pin management in heap_lock_updated_tuple_rec().

  19. Allow tupleslots to have a fixed tupledesc, use in executor nodes.

  20. Expression evaluation based aggregate transition invocation.

  21. Perform slot validity checks in a separate pass over expression.

  22. Rely on executor utils to build targetlist for DML RETURNING.

  23. Refer to OS X as "macOS", except for the port name which is still "darwin".