Re: LLVM 16 (opaque pointers)

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>

To: Andres Freund <andres@anarazel.de>

Cc: 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>, Tom Stellard <tstellar@redhat.com>, Mark Wong <markwkm@gmail.com>

Date: 2023-10-21T23:16:54Z

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 →

jit: Adjust back-patch of f90b4a84 to 12 and 13.
- 9ad98627614b 12.17 landed
- 7c070e224c4a 13.13 landed
Log LLVM library version in configure output.
- 0a6e2c7f8694 11.22 landed
- 527e62a5e5d7 12.17 landed
- a13b63c788a3 13.13 landed
- 03e749c2b89e 14.10 landed
- 0e49e23782c5 15.5 landed
- 3b0f20f6ce14 16.1 landed
- 5e4dacb9878c 17.0 landed
jit: Changes for LLVM 17.
- 7da915e33abf 12.17 landed
- 53c4dabe18d3 13.13 landed
- 0a8b7d5c1126 14.10 landed
- b60e3ac7603d 15.5 landed
- 774185056834 16.1 landed
- 76200e5ee469 17.0 landed
jit: Supply LLVMGlobalGetValueType() for LLVM < 8.
- 60596f148a66 16.1 landed
- d701f0d1f3e7 12.17 landed
- 981292c19f38 13.13 landed
- ee3e4c41f354 14.10 landed
- b2e097788663 15.5 landed
- f90b4a846b32 17.0 landed
jit: Support opaque pointers in LLVM 16.
- 15ddc9725eb7 12.17 landed
- f28956b239f1 13.13 landed
- 82d9a782a296 14.10 landed
- eed1feb3fee1 15.5 landed
- 74d19ec096df 16.1 landed
- 37d5babb5cfa 17.0 landed
jit: Reference function pointer types via llvmjit_types.c.
- df99ddc70b97 14.0 cited

On Sat, Oct 21, 2023 at 7:08 PM Andres Freund <andres@anarazel.de> wrote:
> I've attached a patch revision that I spent the last couple hours working
> on. It's very very roughly based on a patch Tom Stellard had written (which I
> think a few rpm packages use). But instead of encoding details about specific
> layout details, I made the code check if the data layout works and fall back
> to the cpu / features used for llvmjit_types.bc.  This way it's not s390x
> specific, future odd architecture behaviour would "automatically" be handled
> the same

The explanation makes sense and this seems like a solid plan to deal
with it.  I didn't try on a s390x, but I tested locally on our master
branch with LLVM 7, 10, 17, 18, and then I hacked your patch to take
the fallback path as if a layout mismatch had been detected, and it
worked fine:

2023-10-22 11:49:55.663 NZDT [12000] DEBUG:  detected CPU "skylake",
with features "...", resulting in layout
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
2023-10-22 11:49:55.664 NZDT [12000] DEBUG:  detected CPU / features
yield incompatible data layout, using values from module instead
2023-10-22 11:49:55.664 NZDT [12000] DETAIL:  module CPU "x86-64",
features "...", resulting in layout
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"

+    To deal with that, check if data layouts match during JIT
initialization. If
+    the runtime detected cpu / features result in a different layout,
try if the
+    cpu/features recorded in in llvmjit_types.bc work.

s|try |check |
s| in in | in |

+                                       errmsg_internal("could not
determine working CPU / feature comination for JIT compilation"),

s|comination|combination|
s| / |/|g