MIME-Version: 1.0
References: <CA+hUKGKNX_=f+1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw@mail.gmail.com>
 <5716086.DvuYhMxLoT@aivenlaptop> <CA+hUKGLxVtLCo3xD1OEnMSQbq04MKx1G_vQ5SZQNMBSFPR_TpA@mail.gmail.com>
 <2700884.mvXUDI8C0e@aivenlaptop> <CA+hUKGKnLnJnWrkr=4mSGhE5FuTK55FY15uULR7=zzc=wX4Nqw@mail.gmail.com>
 <CA+hUKGKtUB=-BQZd=u4BFZ-UJWi47fekwiYMSDXDZMyV+z1G-g@mail.gmail.com>
 <CA+hUKG+hopeRBGVwS4JE3uy1UO3TRnhF08HMiSpMrPODgtiw9Q@mail.gmail.com> <20231021060805.of3ukvyfmxnlvwcd@awork3.anarazel.de>
In-Reply-To: <20231021060805.of3ukvyfmxnlvwcd@awork3.anarazel.de>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sun, 22 Oct 2023 12:16:54 +1300
Message-ID: <CA+hUKGLuLyntaBEJNt2yu==T+vy8oU0S6J-dR4dTykgBhdF1zw@mail.gmail.com>
Subject: Re: LLVM 16 (opaque pointers)
To: Andres Freund <andres@anarazel.de>
Cc: Ronan Dunklau <ronan.dunklau@aiven.io>, =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= <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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGLuLyntaBEJNt2yu%3D%3DT%2Bvy8oU0S6J-dR4dTykgBhdF1zw%40mail.gmail.com>
Precedence: bulk

On Sat, Oct 21, 2023 at 7:08=E2=80=AFPM 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 (whi=
ch I
> think a few rpm packages use). But instead of encoding details about spec=
ific
> layout details, I made the code check if the data layout works and fall b=
ack
> to the cpu / features used for llvmjit_types.bc.  This way it's not s390x
> specific, future odd architecture behaviour would "automatically" be hand=
led
> 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