Thread: pgsql: Track LLVM 15 changes.
Track LLVM 15 changes. This isn't an API change, it's just a missing #include that we got away with before. Per buildfarm animal seawasp. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/0052fb489008a68d0f3e0445f52e1ab3166632a4 Modified Files -------------- src/backend/jit/llvm/llvmjit_inline.cpp | 1 + 1 file changed, 1 insertion(+)
Hello Thomas, > This isn't an API change, it's just a missing #include that we got away > with before. Per buildfarm animal seawasp. If it is a somehow *missing* include, should it be back-patched? Not sure, just asking. -- Fabien.
On Tue, Feb 15, 2022 at 4:06 AM Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > This isn't an API change, it's just a missing #include that we got away > > with before. Per buildfarm animal seawasp. > > If it is a somehow *missing* include, should it be back-patched? Not sure, > just asking. Arguably (I think it'd work fine on ancient LLVM as far back as we currently support, based on the age of that header[1]), but since there's no actual problem with older LLVM releases, I figured we should let sleeping dogs lie. My general plan for this stuff is to try to do just one back-patch for each LLVM release, with all the changes in it, to reduce commit churn. Hence commit messages that say "Track LLVM X ..." so that it's easy to find all the changes for X around the time of X's release. In other words I'll probably do the 14 back-patch next month, so our May releases will compile and work against LLVM 14, due out in March. Then I'll scoop up the accumulated 15 stuff around October or whatever it turns out to be. (With 13 I "pre-empted" their release with commit 9b4e4cfe, because we could still compile OK against 13 but we would crash on some queries, so it seemed worth the extra effort to avoid having that situation in the field, but I'm not sure if releasing "before" them is really sustainable; I'd have had to get the 14 changes into our recent release, before their RC1.) Open to better ideas about how we should manage this stuff. [1] https://github.com/llvm/llvm-project/blob/llvmorg-3.9.0/llvm/include/llvm/Support/MemoryBuffer.h
On 2022-Feb-15, Thomas Munro wrote: > My general plan for this stuff is to try to do just one back-patch for > each LLVM release, with all the changes in it, to reduce commit churn. > Hence commit messages that say "Track LLVM X ..." so that it's easy to > find all the changes for X around the time of X's release. In other > words I'll probably do the 14 back-patch next month, so our May > releases will compile and work against LLVM 14, due out in March. In this case, maybe you should get this task listed in RELEASE_CHANGES. -- Álvaro Herrera
On Tue, Feb 15, 2022 at 10:22 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2022-Feb-15, Thomas Munro wrote: > > My general plan for this stuff is to try to do just one back-patch for > > each LLVM release, with all the changes in it, to reduce commit churn. > > Hence commit messages that say "Track LLVM X ..." so that it's easy to > > find all the changes for X around the time of X's release. In other > > words I'll probably do the 14 back-patch next month, so our May > > releases will compile and work against LLVM 14, due out in March. > > In this case, maybe you should get this task listed in RELEASE_CHANGES. This really depends on *their* release cycle, not ours. Hmm. Well, if we had a buildfarm animal that ran their latest release branch as recently discussed, not their main branch, then we could say "if that machine is failing, but seawasp is passing, now is the time to back-patch all the 'Track LLVM X' patches; if seawasp is failing, we should urgently look into why". I'm willing to set such an animal up, but Fabien or Andres may want to... A bit of shell scripting to peek at their branches or look for their RC1 tag or something like that depending on what we decide is the right trigger point.
Thomas Munro <thomas.munro@gmail.com> writes:
> This really depends on *their* release cycle, not ours. Hmm. Well,
> if we had a buildfarm animal that ran their latest release branch as
> recently discussed, not their main branch, then we could say "if that
> machine is failing, but seawasp is passing, now is the time to
> back-patch all the 'Track LLVM X' patches; if seawasp is failing, we
> should urgently look into why". I'm willing to set such an animal up,
> but Fabien or Andres may want to... A bit of shell scripting to peek
> at their branches or look for their RC1 tag or something like that
> depending on what we decide is the right trigger point.
Although seawasp isn't actually failing at the moment, it's emitting
a boatload of deprecation warnings, eg
In file included from llvmjit_deform.c:27:
../../../../src/include/jit/llvmjit_emit.h:112:23: warning: 'LLVMBuildStructGEP' is deprecated: Use LLVMBuildStructGEP2
insteadto support opaque pointers [-Wdeprecated-declarations]
LLVMValueRef v_ptr = LLVMBuildStructGEP(b, v, idx, "");
^
/home/fabien/clgtk/include/llvm-c/Core.h:3908:1: note: 'LLVMBuildStructGEP' has been explicitly marked deprecated here
LLVM_ATTRIBUTE_C_DEPRECATED(
^
Is that on anyone's radar to clean up?
regards, tom lane
On Wed, Feb 16, 2022 at 7:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Although seawasp isn't actually failing at the moment, it's emitting > a boatload of deprecation warnings, eg > > In file included from llvmjit_deform.c:27: > ../../../../src/include/jit/llvmjit_emit.h:112:23: warning: 'LLVMBuildStructGEP' is deprecated: Use LLVMBuildStructGEP2instead to support opaque pointers [-Wdeprecated-declarations] > LLVMValueRef v_ptr = LLVMBuildStructGEP(b, v, idx, ""); > ^ > /home/fabien/clgtk/include/llvm-c/Core.h:3908:1: note: 'LLVMBuildStructGEP' has been explicitly marked deprecated here > LLVM_ATTRIBUTE_C_DEPRECATED( > ^ > > Is that on anyone's radar to clean up? Yeah I mentioned this problem in the other thread. I got as far as finding this write-up: https://llvm.org/docs/OpaquePointers.html I haven't yet tried to work out what we really need to do, but I'm planning to try. Possibly requires a bit more book keeping on our part, since eg LLVMGetElementType() is going away.
Hi, On 2022-02-16 09:18:53 +1300, Thomas Munro wrote: > Yeah I mentioned this problem in the other thread. I got as far as > finding this write-up: > > https://llvm.org/docs/OpaquePointers.html Given that major parts of llvm (clang alone contains ~1k references) aren't yet transitioned, I wonder if should silence them for now? > I haven't yet tried to work out what we really need to do, but I'm > planning to try. Possibly requires a bit more book keeping on our > part, since eg LLVMGetElementType() is going away. I can't yet really tell whether it'll be simpler because pointer types aren't a thing anymore, or harder because the llvmjit_types.c mechanism won't work well anymore. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > On 2022-02-16 09:18:53 +1300, Thomas Munro wrote: >> Yeah I mentioned this problem in the other thread. I got as far as >> finding this write-up: >> https://llvm.org/docs/OpaquePointers.html > Given that major parts of llvm (clang alone contains ~1k references) aren't > yet transitioned, I wonder if should silence them for now? For my own part, I don't have any problem with just filtering these warnings for now. I don't need any buildfarm changes for that. regards, tom lane
On Wed, Feb 16, 2022 at 11:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2022-02-16 09:18:53 +1300, Thomas Munro wrote: > >> Yeah I mentioned this problem in the other thread. I got as far as > >> finding this write-up: > >> https://llvm.org/docs/OpaquePointers.html > > > Given that major parts of llvm (clang alone contains ~1k references) aren't > > yet transitioned, I wonder if should silence them for now? > > For my own part, I don't have any problem with just filtering these > warnings for now. I don't need any buildfarm changes for that. Shortly I'll do the back-patch of LLVM 14 API changes (their final release tag is scheduled for tomorrow, as I've been reminded by package maintainers trying and failing to build). But I figured I should also follow up on this bandaid solution to the API deprecation warnings, that is, silencing them for now, so we don't spew screeds of warnings. Does someone have a better idea than the attached?
Attachment
Hi, On 2022-03-15 12:12:44 +1300, Thomas Munro wrote: > Shortly I'll do the back-patch of LLVM 14 API changes (their final > release tag is scheduled for tomorrow, as I've been reminded by > package maintainers trying and failing to build). +1 > But I figured I > should also follow up on this bandaid solution to the API deprecation > warnings, that is, silencing them for now, so we don't spew screeds of > warnings. Does someone have a better idea than the attached? Hm. No, no I don't see something better. There's ugly stuff like redefining LLVM_ATTRIBUTE_DEPRECATED but that seems worse. Greetings, Andres Freund
On Wed, Feb 16, 2022 at 9:18 AM Thomas Munro <thomas.munro@gmail.com> wrote: > On Wed, Feb 16, 2022 at 7:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Although seawasp isn't actually failing at the moment, it's emitting > > a boatload of deprecation warnings, eg > > > > In file included from llvmjit_deform.c:27: > > ../../../../src/include/jit/llvmjit_emit.h:112:23: warning: 'LLVMBuildStructGEP' is deprecated: Use LLVMBuildStructGEP2instead to support opaque pointers [-Wdeprecated-declarations] > > LLVMValueRef v_ptr = LLVMBuildStructGEP(b, v, idx, ""); > > ^ > > /home/fabien/clgtk/include/llvm-c/Core.h:3908:1: note: 'LLVMBuildStructGEP' has been explicitly marked deprecated here > > LLVM_ATTRIBUTE_C_DEPRECATED( > > ^ > > > > Is that on anyone's radar to clean up? > > Yeah I mentioned this problem in the other thread. I got as far as > finding this write-up: > > https://llvm.org/docs/OpaquePointers.html > > I haven't yet tried to work out what we really need to do, but I'm > planning to try. Possibly requires a bit more book keeping on our > part, since eg LLVMGetElementType() is going away. And now seaswap fails with an assertion about that. I'll try to have a look this week. Just to be clear, this is an LLVM 15-to-be problem so we have some time. #3 0x00007f5eea78e006 in __GI___assert_fail (assertion=0x7f5edce1d730 "NumContainedTys && \\"Attempting to get element type of opaque pointer\\"", file=0x7f5edce1d668 "/home/fabien/llvm-src/llvm/include/llvm/IR/Type.h", line=380, function=0x7f5edce1d6d0 "llvm::Type* llvm::Type::getNonOpaquePointerElementType() const") at assert.c:101 #4 0x00007f5edca8deae in llvm::Type::getNonOpaquePointerElementType (this=0x561441f6eb40) at /home/fabien/llvm-src/llvm/include/llvm/IR/Type.h:380 #5 0x00007f5edcb6e54f in LLVMGetElementType (WrappedTy=0x561441f6eb40) at /home/fabien/llvm-src/llvm/lib/IR/Core.cpp:801 #6 0x00007f5edf85ffe0 in llvm_pg_var_type () from /home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so #7 0x00007f5edf85f102 in llvm_create_context () from /home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so #8 0x00007f5edf86a3c9 in llvm_compile_expr () from /home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so #9 0x00005614404c24d4 in ExecBuildProjectionInfo () #10 0x00005614404deb92 in ExecAssignProjectionInfo () #11 0x0000561440505724 in ExecInitNestLoop () #12 0x00005614404d7851 in ExecInitNode () #13 0x0000561440508064 in ExecInitSort () #14 0x00005614404d78ab in ExecInitNode () #15 0x00005614404cfe92 in standard_ExecutorStart () #16 0x0000561440687846 in PortalStart () #17 0x0000561440686cbc in exec_simple_query () #18 0x000056144068491d in PostgresMain () #19 0x00005614405e24bb in BackendRun () #20 0x00005614405e1d1a in ServerLoop () #21 0x00005614405df217 in PostmasterMain () #22 0x000056144052dc0c in main ()