public inbox for [email protected]
help / color / mirror / Atom feedFrom: Thomas Munro <[email protected]>
To: Andres Freund <[email protected]>
Cc: Ronan Dunklau <[email protected]>
Cc: Devrim Gündüz <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Fabien COELHO <[email protected]>
Cc: Dmitry Dolgov <[email protected]>
Cc: Tom Stellard <[email protected]>
Cc: Mark Wong <[email protected]>
Subject: Re: LLVM 16 (opaque pointers)
Date: Sun, 22 Oct 2023 12:16:54 +1300
Message-ID: <CA+hUKGLuLyntaBEJNt2yu==T+vy8oU0S6J-dR4dTykgBhdF1zw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
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>
<[email protected]>
On Sat, Oct 21, 2023 at 7:08 PM Andres Freund <[email protected]> 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
view thread (21+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: LLVM 16 (opaque pointers)
In-Reply-To: <CA+hUKGLuLyntaBEJNt2yu==T+vy8oU0S6J-dR4dTykgBhdF1zw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox