From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Thomas Munro <thomas.munro@gmail.com>
Subject: Re: LLVM 16 (opaque pointers)
Date: Thu, 10 Aug 2023 16:56:54 +0200
Message-ID: <6965583.LvFx2qVVIh@aivenlaptop>
In-Reply-To: 
 <CA+hUKGKNX_=f+1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw@mail.gmail.com>
References: 
 <_QHm0YiFiSfB_XrqU31J6iQ4rZZBBv_hBslJrGXEq0RT-anIrSFF2NVNT582qTw4H9CGeYURmFKHTtRw47tVMQ==@protonmail.internalid>
 <CA+hUKGKNX_=f+1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/6965583.LvFx2qVVIh%40aivenlaptop>
Precedence: bulk

Le dimanche 21 mai 2023, 05:01:41 CEST Thomas Munro a =E9crit :
> Hi,
>=20
> Here is a draft version of the long awaited patch to support LLVM 16.
> It's mostly mechanical donkeywork, but it took some time: this donkey
> found it quite hard to understand the mighty getelementptr
> instruction[1] and the code generation well enough to figure out all
> the right types, and small mistakes took some debugging effort*.  I
> now finally have a patch that passes all tests.
>=20
> Though it's not quite ready yet, I thought I should give this status
> update to report that the main task is more or less complete, since
> we're starting to get quite a few emails about it (mostly from Fedora
> users) and there is an entry for it on the Open Items for 16 wiki
> page.  Comments/review/testing welcome.

Hello Thomas,

Thank you for this effort !

I've tested it against llvm 15 and 16, and found no problem with it.

> 6. I need to go through the types again with a fine tooth comb, and
> check the test coverage to look out for eg GEP array arithmetic with
> the wrong type/size that isn't being exercised.

I haven't gone through the test coverage myself, but I exercised the follow=
ing=20
things:=20

 - running make installcheck with jit_above_cost =3D 0
 - letting sqlsmith hammer random queries at it for a few hours.

This didn't show obvious issues.

> *For anyone working with this type of IR generation code and
> questioning their sanity, I can pass on some excellent advice I got
> from Andres: build LLVM yourself with assertions enabled, as they
> catch some classes of silly mistake that otherwise just segfault
> > inscrutably on execution.

I tried my hand at backporting it to previous versions, and not knowing=20
anything about it made me indeed question my sanity.  It's quite easy for P=
G=20
15, 14, 13. PG 12 is nothing insurmontable either, but PG 11 is a bit hairi=
er=20
most notably due to to the change in fcinfo args representation. But I gues=
s=20
that's also a topic for another day :-)

Best regards,

=2D-
Ronan Dunklau