JIT compiling with LLVM v11 - Mailing list pgsql-hackers

From Andres Freund
Subject JIT compiling with LLVM v11
Date
Msg-id 20180301080242.jfxnwbwr2mu3k2ng@alap3.anarazel.de
Whole thread Raw
In response to [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0  (Andres Freund <andres@anarazel.de>)
Responses Re: JIT compiling with LLVM v11  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: JIT compiling with LLVM v11  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Hi,

I've pushed a revised version of my JIT patchset.
The git tree is at
  https://git.postgresql.org/git/users/andresfreund/postgres.git
in the jit branch
  https://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/jit

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
@"pgextern.$libdir/hstore.hstore_from_record".

  Both symbol resolution and inlining knows how to properly resolve
  those.

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

  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.


Regards,

Andres


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Online enabling of checksums
Next
From: Andres Freund
Date:
Subject: Re: Online enabling of checksums