Horton

Re: LLVM 16 (opaque pointers)

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Mark Wong <markwkm@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ronan Dunklau <ronan.dunklau@aiven.io>, Devrim Gündüz <devrim@gunduz.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Fabien COELHO <coelho@cri.ensmp.fr>, Dmitry Dolgov <9erthalion6@gmail.com>, Andres Freund <andres@anarazel.de>
Date: 2023-10-23T21:17:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. jit: Adjust back-patch of f90b4a84 to 12 and 13.

  2. Log LLVM library version in configure output.

  3. jit: Changes for LLVM 17.

  4. jit: Supply LLVMGlobalGetValueType() for LLVM < 8.

  5. jit: Support opaque pointers in LLVM 16.

  6. jit: Reference function pointer types via llvmjit_types.c.

On Tue, Oct 24, 2023 at 4:27 AM Mark Wong <markwkm@gmail.com> wrote:
> I haven't gotten around to disabling llvm on any of my animals with llvm
> < 7 yet.  Do you still want to hold on that?

Yes, please disable --with-llvm on s390x and POWER animals with LLVM <
7 (see below).  Also, you have a bunch of machines with LLVM 16 that
are failing to compile on REL_11_STABLE.  That is expected, because we
agreed not to back-patch the LLVM 16 API changes into REL_11_STABLE:

> kingsnake: 16.0.6 Fedora Linux 38
> krait: CentOS 16.0.6 Stream 8
> lancehead: CentOS 16.0.6 Stream 8

These POWER machines fail as expected, and it's unfixable:

> elasmobranch: 5.0.1 openSUSE Leap 15.0
> demoiselle: 5.0.1 openSUSE Leap 15.0
> cavefish: 6.0.0 Ubuntu 18.04.6 LTS

(Well, we could in theory supply our own fixed
llvm::orc::createLocalIndirectStubsManagerBuilder() function to hide
the broken one in LLVM <= 6, but that way lies madness IMHO.  An LTS
distro that cares could look into back-patching LLVM's fixes, but for
us, let us focus on current software.)

This POWER animal fails, unexpectedly to me:

> bonito: 7.0.1 Fedora 29

We could try to chase that down, or we could rejoice that at least it
works on current release.  It must begin working somewhere between 7
and 11, but when I checked which LLVM releases I could easily install
on eg cascabel (if I could get access) using the repo at apt.llvm.org,
I saw that they don't even have anything older than 11.  So someone
with access who wants to figure this out might have many days or weeks
of compiling ahead of them.

These POWER animals are passing, as expected:

> cascabel: 11.0.1 Debian GNU/Linux 11
> babbler: 15.0.7 AlmaLinux 8.8
> pytilia: 15.0.7 AlmaLinux 8.8
> nicator: 15.0.7 AlmaLinux 9.2
> twinspot: 15.0.7 AlmaLinux 9.2
> habu: 16.0.6 Fedora Linux 38
> kingsnake: 16.0.6 Fedora Linux 38
> krait: CentOS 16.0.6 Stream 8
> lancehead: CentOS 16.0.6 Stream 8

These s390x animals are passing:

> branta: 10.0.0 Ubuntu 20.04.4 LTS
> pike: 11.0.1 Debian GNU/Linux 11
> rinkhals: 11.0.1 Debian GNU/Linux 11
> sarus: 14.0.0 Ubuntu 22.04.1 LTS

These s390x animals are failing, but don't show the layout complaint.
I can see that LLVM 6 also lacked a case for s390x in
llvm::orc::createLocalIndirectStubsManagerBuilder(), the thing that
was fixed in 7 with the addition of a default case.  Therefore these
presumably fail just like old LLVM on POWER, and it's unfixable.  So I
suggest turning off --with-llvm on these two:

> cotinga: 6.0.0 Ubuntu 18.04.6 LTS
> perch: 6.0.0 Ubuntu 18.04.6 LTS

These s390x animals are failing with the mismatched layout problem,
which should be fixed by Andres's patch to tolerate the changing
z12/z13 ABI thing by falling back to whatever clang picked (at a cost
of not using all the features of your newer CPU, unless you explicitly
tell clang to target it):

> aracari: 15.0.7 Red Hat Enterprise Linux 8.6
> pipit: 15.0.7 Red Hat Enterprise Linux 8.6
> lora: 15.0.7 Red Hat Enterprise Linux 9.2

This s390x animal doesn't actually have --with-llvm enabled so it
passes, but surely it'd be just like lora:

> mamushi: 15.0.7 Red Hat Enterprise Linux 9.2