JIT compiling with LLVM v11

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>
Subject: JIT compiling with LLVM v11
Date: 2018-03-01 08:02:42
Message-ID: 20180301080242.jfxnwbwr2mu3k2ng@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I've pushed a revised version of my JIT patchset.
The git tree is at
in the jit branch

Biggest changes:
- LLVM 3.9 - master are now supported. This includes a good chunk of
work by Pierre Ducroquet.

Doing so I found that the patches Pierre provided didn't work when a
query was expensive enough to warrant inlining. Turns out LLVM < 5
can't combine the summaries of multiple thin module summaries.

But that actually turned out to be a good thing, because it made me
think about symbol resolution preferences. Previously it was basically
arbitrary whether a function with conflicting names would be choosen
from core postgres or one of the extension libs providing it.

This is now rewritten so we don't build a combined module summary for
core postgres and extensions at backend start. Instead summaries for
core pg and extensions are loaded separately, and the correct one for
a symbol is used.

- Functions in extension libraries are now not referred to with their C
symbol in LLVM IR, instead we generate a fictious symbol that includes
the library path. E.g. hstore's hstore_from_record is now referenced as

Both symbol resolution and inlining knows how to properly resolve

- As hinted to above, the inlining support has evolved
considerably. Instead of a combined index built at backend start we
now have individual indexes for each extension / shlib. Symbols are
searched with a search path (internal functions just in the 'postgres'
index, for extensions it's main 'postgres', 'extension'), and symbols
that explicitly reference a function are just looked up within that

This has the nice advantage that we don't have to process indexes for
extensions that aren't used, which in turn means that extensions can
be installed on the system level while a backend is running, and
JITing will work even for old backends once the extension is created
(or rather functions in it).

Additionally the inline costing logic has improved, the super verbose
logging is #ifdef'ed out ('ilog' wrapper that's just (void) 0).

- The installation of bitcode is now a nice separate make function. pgxs
(including contrib's kinda use of pgxs) now automatically generate &
install bitcode when the server was compiled --with-llvm.

I learned some about make I didn't know ;).

- bunch of compilation issues (older clang, -D_NDEBUG from llvm-config
being used for all of postgres, ...) have been fixed.

- Two bigger prerequisite patches have been merged.

- lotsa smaller stuff.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-03-01 08:04:01 Re: Online enabling of checksums
Previous Message Michael Paquier 2018-03-01 08:00:49 Re: Online enabling of checksums