Horton

Re: LLVM 16 (opaque pointers)

Dmitry Dolgov <9erthalion6@gmail.com>

View thread
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, Devrim Gündüz <devrim@gunduz.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Fabien COELHO <coelho@cri.ensmp.fr>, Ronan Dunklau <ronan.dunklau@aiven.io>
Date: 2023-10-13T14:44:13Z
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.

Attachments

> On Fri, Oct 13, 2023 at 11:06:21AM +0200, Dmitry Dolgov wrote:
> > On Thu, Oct 12, 2023 at 04:31:20PM -0700, Andres Freund wrote:
> > I don't think the "function(no-op-function),no-op-module" bit does something
> > particularly useful?
>
> Right, looks like leftovers after verifying which passes were actually
> applied. My bad, could be removed.
>
> > I also don't think we should add the mem2reg pass outside of -O0 - running it
> > after a real optimization pipeline doesn't seem useful and might even make the
> > code worse? mem2reg is included in default<O1> (and obviously also in O3).
>
> My understanding was that while mem2reg is included everywhere above
> -O0, this set of passes won't hurt. But yeah, if you say it could
> degrade the final result, it's better to not do this. I'll update this
> part.

Here is what I had in mind (only this part in the second patch was changed).