pgsql: jit: Support opaque pointers in LLVM 16.

Started by Thomas Munroalmost 3 years ago3 messageshackerscomitters
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

won't retrysuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t48609
psql -h localhost -U postgres

Built from patchset v3 (message #3), July 27, 2026 at 11:52 PM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t48609_3 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t48609_3 && git checkout t48609_3

Patchset v3 (message #3) is on t48609_3

Jump to latest
#1Thomas Munro
thomas.munro@gmail.com
hackerscomitters

jit: Support opaque pointers in LLVM 16.

Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1]https://llvm.org/docs/OpaquePointers.html.

* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.
* For LLVM == 15, we'll continue to do the same, explicitly opting
out of opaque pointer mode.
* For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take
the extra type argument.

The difference is hidden behind some new IR emitting wrapper functions
l_load(), l_gep(), l_call() etc. The change is mostly mechanical,
except that at each site the correct type had to be provided.

In some places we needed to do some extra work to get functions types,
including some new wrappers for C++ APIs that are not yet exposed by in
LLVM's C API, and some new "example" functions in llvmjit_types.c
because it's no longer possible to start from the function pointer type
and ask for the function type.

Back-patch to 12, because it's a little tricker in 11 and we agreed not
to put the latest LLVM support into the upcoming final release of 11.

[1]: https://llvm.org/docs/OpaquePointers.html

Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Ronan Dunklau <ronan.dunklau@aiven.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: /messages/by-id/CA+hUKGKNX_=f+1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/37d5babb5cfa4c6795b3cb6de964ba019d3d60ab

Modified Files
--------------
src/backend/jit/llvm/llvmjit.c | 59 ++---
src/backend/jit/llvm/llvmjit_deform.c | 119 +++++-----
src/backend/jit/llvm/llvmjit_expr.c | 401 ++++++++++++++++++++--------------
src/backend/jit/llvm/llvmjit_types.c | 39 +++-
src/backend/jit/llvm/llvmjit_wrap.cpp | 12 +
src/backend/jit/llvm/meson.build | 2 +-
src/include/jit/llvmjit.h | 7 +
src/include/jit/llvmjit_emit.h | 106 ++++++---
8 files changed, 481 insertions(+), 264 deletions(-)

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Munro (#1)
hackerscomitters
Re: pgsql: jit: Support opaque pointers in LLVM 16.

Thomas Munro <tmunro@postgresql.org> writes:

jit: Support opaque pointers in LLVM 16.

I chanced to notice that the configure script (and meson too) is
still doing

PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-Xclang -no-opaque-pointers])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-Xclang -no-opaque-pointers])

Shouldn't we remove that now?

regards, tom lane

#3Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Thomas Munro (#1)
hackerscomitters
Re: pgsql: jit: Support opaque pointers in LLVM 16.

On 2023-Oct-18, Thomas Munro wrote:

jit: Support opaque pointers in LLVM 16.

Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1].

* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.

I have LLVM 14 (whatever Debian ships[*]), and running headerscheck results
in a bunch of warnings from this:

In file included from /tmp/headerscheck.s89Gdv/test.c:2:
/pgsql/source/master/src/include/jit/llvmjit_emit.h: In function ‘l_call’:
/pgsql/source/master/src/include/jit/llvmjit_emit.h:141:9: warning: ‘LLVMBuildCall’ is deprecated [-Wdeprecated-declarations]
141 | return LLVMBuildCall(b, fn, args, nargs, name);
| ^~~~~~
In file included from /usr/include/llvm-c/Core.h:18,
from /pgsql/source/master/src/include/jit/llvmjit_emit.h:18:
/usr/include/llvm-c/Core.h:3991:1: note: declared here
3991 | LLVM_ATTRIBUTE_C_DEPRECATED(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~

These warnings go away if I change the conditional from
LLVM_VERSION_MAJOR < 16 to 14.

Let's ... do that? As in the attached patch.

In 13, there's a comment about it being deprecated, but no macro to make
the compiler whine:
https://github.com/hdoc/llvm-project/blob/release/13.x/llvm/include/llvm-c/Core.h#L3953

This changed in 14:
https://github.com/hdoc/llvm-project/blob/release/14.x/llvm/include/llvm-c/Core.h#L3898

[*] apt policy llvm:
llvm:
Installed: 1:14.0-55.7~deb12u1
Candidate: 1:14.0-55.7~deb12u1
Version table:
*** 1:14.0-55.7~deb12u1 500
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

Attachments:

t48609_3
0001-use-non-deprecated-LLVM-functions-starting-with-its-.patchtext/x-diff; charset=utf-8Download+4-5