[PATCH] Fix build with LLVM 15 or above
Hello,
While building PostgreSQL 15 RC 1 with LLVM 15, I got a build failure as
follows:
cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -Wcast-function-type -Wformat-security
-fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument
-Wno-compound-token-split-by-macro -O2 -pipe -O3 -funroll-loops
-fstack-protector-strong -fno-strict-aliasing -Wno-deprecated-declarations
-fPIC -DPIC -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_CONSTANT_MACROS -I/usr/local/llvm15/include
-I../../../../src/include -I/usr/local/include -I/usr/local/include
-I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include -c -o llvmjit.o llvmjit.c
llvmjit.c:1115:50: error: use of undeclared identifier
'LLVMJITCSymbolMapPair'
LLVMOrcCSymbolMapPairs symbols =
palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);
^
llvmjit.c:1233:81: error: too few arguments to function call, expected 3,
have 2
ref_gen =
LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^
/usr/local/llvm15/include/llvm-c/Orc.h:997:31: note:
'LLVMOrcCreateCustomCAPIDefinitionGenerator' declared here
LLVMOrcDefinitionGeneratorRef LLVMOrcCreateCustomCAPIDefinitionGenerator(
^
2 errors generated.
gmake: *** [<builtin>: llvmjit.o] Error 1
*** Error code 2
I've prepared a patch (attached) to fix the build issue with LLVM 15 or
above. It is also available at
https://people.FreeBSD.org/~sunpoet/patch/postgres/0001-Fix-build-with-LLVM-15-or-above.patch
Thanks.
Regards,
sunpoet
Attachments:
0001-Fix-build-with-LLVM-15-or-above.patchapplication/x-patch; name=0001-Fix-build-with-LLVM-15-or-above.patchDownload
From bd2f6d2ec5369b5e33c6bf41560cdae3f8088f07 Mon Sep 17 00:00:00 2001
From: Po-Chuan Hsieh <sunpoet@sunpoet.net>
Date: Sat, 1 Oct 2022 22:23:41 +0800
Subject: [PATCH] Fix build with LLVM 15 or above
- Upstream has fixed the struct name prefix from LLVMJIT to LLVMOrc [1].
- Upstream has changed the API of LLVMOrcCreateCustomCAPIDefinitionGenerator [2].
Reference: https://github.com/llvm/llvm-project/commit/b425f556935c1105dea59871a46caa7af2d378ad [1]
https://github.com/llvm/llvm-project/commit/14b7c108a2bf46541efc3a5c9cbd589b3afc18e6 [2]
---
src/backend/jit/llvm/llvmjit.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c
index fd3eecf27d..731b28a4c9 100644
--- a/src/backend/jit/llvm/llvmjit.c
+++ b/src/backend/jit/llvm/llvmjit.c
@@ -1112,7 +1112,11 @@ llvm_resolve_symbols(LLVMOrcDefinitionGeneratorRef GeneratorObj, void *Ctx,
LLVMOrcJITDylibRef JD, LLVMOrcJITDylibLookupFlags JDLookupFlags,
LLVMOrcCLookupSet LookupSet, size_t LookupSetSize)
{
+#if LLVM_VERSION_MAJOR >= 15
+ LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMOrcCSymbolMapPair) * LookupSetSize);
+#else
LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);
+#endif
LLVMErrorRef error;
LLVMOrcMaterializationUnitRef mu;
@@ -1230,7 +1234,11 @@ llvm_create_jit_instance(LLVMTargetMachineRef tm)
* Symbol resolution support for "special" functions, e.g. a call into an
* SQL callable function.
*/
+#if LLVM_VERSION_MAJOR >= 15
+ ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL, NULL);
+#else
ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
+#endif
LLVMOrcJITDylibAddGenerator(LLVMOrcLLJITGetMainJITDylib(lljit), ref_gen);
return lljit;
--
2.35.2
On Mon, Oct 3, 2022 at 4:56 PM Po-Chuan Hsieh <sunpoet@sunpoet.net> wrote:
While building PostgreSQL 15 RC 1 with LLVM 15, I got a build failure as follows:
cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -O2 -pipe -O3 -funroll-loops -fstack-protector-strong -fno-strict-aliasing -Wno-deprecated-declarations -fPIC -DPIC -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -I/usr/local/llvm15/include -I../../../../src/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -c -o llvmjit.o llvmjit.c
llvmjit.c:1115:50: error: use of undeclared identifier 'LLVMJITCSymbolMapPair'
LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);
^
llvmjit.c:1233:81: error: too few arguments to function call, expected 3, have 2
ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/llvm15/include/llvm-c/Orc.h:997:31: note: 'LLVMOrcCreateCustomCAPIDefinitionGenerator' declared here
LLVMOrcDefinitionGeneratorRef LLVMOrcCreateCustomCAPIDefinitionGenerator(
^
2 errors generated.
gmake: *** [<builtin>: llvmjit.o] Error 1
*** Error code 2I've prepared a patch (attached) to fix the build issue with LLVM 15 or above. It is also available at https://people.FreeBSD.org/~sunpoet/patch/postgres/0001-Fix-build-with-LLVM-15-or-above.patch
Hi,
Unfortunately that is only the tip of a mini iceberg. While that
change makes it compile, there are other API changes that are required
to make our use of LLVM ORC actually work. We can't get through 'make
check', because various code paths in LLVM 15 abort, because we're
using a bunch of APIs from before the big change to "opaque pointers"
https://llvm.org/docs/OpaquePointers.html. I've been trying to get to
a patch to fix that -- basically a few simple-looking changes like
LLVMBuildLoad() to LLVMBuildLoad2() as described there -- that gain an
argument where you have to tell it the type of the pointer (whereas
before it knew the type of pointers automatically). Unfortunately I
had to work on other problems that came up recently and it's probably
going to be at least a week before I can get back to this and post a
patch.
One option I thought about as a stopgap measure is to use
LLVMContextSetOpaquePointers(context, false) to turn the new code
paths off, but it doesn't seem to work for me and I couldn't figure
out why yet (it still aborts -- probably there are more 'contexts'
around that I didn't handle, something like that). That option is
available for LLVM 15 but will be taken out in LLVM 16, so that's
supposed to be the last chance to stop using pre-opaque pointers; see
the bottom of the page I linked above for that, where they call it
setOpaquePointers(false) (the C++ version of
LLVMContextSetOpaquePointers()). I don't really want to go with that
if we can avoid it, though, because it says "Opaque pointers are
enabled by default. Typed pointers are still available, but only
supported on a best-effort basis and may be untested" so I expect it
to be blighted with problems.
Here's my attempt at that minimal change, which is apparently still
missing something (if you can get this to build and pass all tests
against LLVM 15 then it might still be interesting to know about):
https://github.com/macdice/postgres/tree/llvm15-min
Here's my WIP unfinished branch where I'm trying to get the real code
change done. It needs more work on function pointer types, which are
a bit tedious to deal with and I haven't got it all right in here yet
as you can see from failures if you build against 15:
https://github.com/macdice/postgres/tree/llvm15
Hopefully more next week...
Hi,
On 2022-10-03 18:34:18 +1300, Thomas Munro wrote:
One option I thought about as a stopgap measure is to use
LLVMContextSetOpaquePointers(context, false) to turn the new code
paths off, but it doesn't seem to work for me and I couldn't figure
out why yet (it still aborts -- probably there are more 'contexts'
around that I didn't handle, something like that).
I think that's just because of this hunk:
@@ -992,7 +1000,12 @@ llvm_create_types(void)
}
/* eagerly load contents, going to need it all */
+#if LLVM_VERSION_MAJOR > 14
+ if (LLVMParseBitcodeInContext2(LLVMOrcThreadSafeContextGetContext(llvm_ts_context),
+ buf, &llvm_types_module))
+#else
if (LLVMParseBitcode2(buf, &llvm_types_module))
+#endif
{
elog(ERROR, "LLVMParseBitcode2 of %s failed", path);
}This is the wrong context to use here. Because of that we end up with types
from two different contexts being used, which leads to this assertion to fail:
#5 0x00007f945a036ab2 in __GI___assert_fail (
assertion=0x7f93cf5a4a1b "getOperand(0)->getType() == getOperand(1)->getType() && \"Both operands to ICmp instruction are not of the same type!\"",
file=0x7f93cf66062a "/home/andres/src/llvm-project/llvm/include/llvm/IR/Instructions.h", line=1191,
function=0x7f93cf5f2db6 "void llvm::ICmpInst::AssertOK()") at ./assert/assert.c:101
#6 0x00007f93cf9e3a3c in llvm::ICmpInst::AssertOK (this=0x56482c3b4b50) at /home/andres/src/llvm-project/llvm/include/llvm/IR/Instructions.h:1190
#7 0x00007f93cf9e38ca in llvm::ICmpInst::ICmpInst (this=0x56482c3b4b50, pred=llvm::CmpInst::ICMP_UGE, LHS=0x56482c3b98d0, RHS=0x56482c3b9920, NameStr="")
at /home/andres/src/llvm-project/llvm/include/llvm/IR/Instructions.h:1245
#8 0x00007f93cf9dc6f9 in llvm::IRBuilderBase::CreateICmp (this=0x56482c3b4650, P=llvm::CmpInst::ICMP_UGE, LHS=0x56482c3b98d0, RHS=0x56482c3b9920, Name="")
at /home/andres/src/llvm-project/llvm/include/llvm/IR/IRBuilder.h:2212
#9 0x00007f93cfa650cd in LLVMBuildICmp (B=0x56482c3b4650, Op=LLVMIntUGE, LHS=0x56482c3b98d0, RHS=0x56482c3b9920, Name=0x7f9459722cf2 "")
at /home/andres/src/llvm-project/llvm/lib/IR/Core.cpp:3883
#10 0x00007f945971b4d7 in llvm_compile_expr (state=0x56482c31f878) at /home/andres/src/postgresql/src/backend/jit/llvm/llvmjit_expr.c:302
#11 0x000056482a28f76b in jit_compile_expr (state=state@entry=0x56482c31f878) at /home/andres/src/postgresql/src/backend/jit/jit.c:177
#12 0x0000564829f44e62 in ExecReadyExpr (state=state@entry=0x56482c31f878) at /home/andres/src/postgresql/src/backend/executor/execExpr.c:885
because types (compared by pointer value) are only unique within a context.
I think all that is needed for this aspect would be:
#if LLVM_VERSION_MAJOR > 14
LLVMContextSetOpaquePointers(LLVMGetGlobalContext(), false);
#endif
I haven't yet run through the whole regression test with an assert enabled
llvm because an assert-enabled llvm is *SLOW*, but it got through the first
few parallel groups ok. Using an optimized llvm 15, all tests pass with
PGOPTIONS=-cjit_above_cost=0.
That option is available for LLVM 15 but will be taken out in LLVM 16, so
that's supposed to be the last chance to stop using pre-opaque pointers; see
the bottom of the page I linked above for that, where they call it
setOpaquePointers(false) (the C++ version of
LLVMContextSetOpaquePointers()). I don't really want to go with that if we
can avoid it, though, because it says "Opaque pointers are enabled by
default. Typed pointers are still available, but only supported on a
best-effort basis and may be untested" so I expect it to be blighted with
problems.
I think it'd be ok for the back branches, while we figure out the opaque stuff
in HEAD.
Greetings,
Andres Freund
Attachments:
v1-0001-WIP-jit-LLVM-15-Minimal-changes.patchtext/x-diff; charset=us-asciiDownload
From d2a383fe07f962e3a1e17a7f8f112a868cbd8175 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 22 Sep 2022 23:38:56 +1200
Subject: [PATCH v1] WIP: jit: LLVM 15: Minimal changes.
Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque
pointers still exists and we can request that on our context. We have
until LLVM 16 to move to opaque pointers.
---
src/backend/jit/llvm/llvmjit.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c
index fd3eecf27d3..bccfcfa9698 100644
--- a/src/backend/jit/llvm/llvmjit.c
+++ b/src/backend/jit/llvm/llvmjit.c
@@ -798,6 +798,16 @@ llvm_session_initialize(void)
LLVMInitializeNativeAsmPrinter();
LLVMInitializeNativeAsmParser();
+ /*
+ * When targetting an llvm version with opaque pointers enabled by
+ * default, turn them off for the context we build our code in. Don't need
+ * to do so for other contexts (e.g. llvm_ts_context) - once the IR is
+ * generated, it carries the necessary information.
+ */
+#if LLVM_VERSION_MAJOR > 14
+ LLVMContextSetOpaquePointers(LLVMGetGlobalContext(), false);
+#endif
+
/*
* Synchronize types early, as that also includes inferring the target
* triple.
@@ -1112,7 +1122,11 @@ llvm_resolve_symbols(LLVMOrcDefinitionGeneratorRef GeneratorObj, void *Ctx,
LLVMOrcJITDylibRef JD, LLVMOrcJITDylibLookupFlags JDLookupFlags,
LLVMOrcCLookupSet LookupSet, size_t LookupSetSize)
{
+#if LLVM_VERSION_MAJOR > 14
+ LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMOrcCSymbolMapPair) * LookupSetSize);
+#else
LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);
+#endif
LLVMErrorRef error;
LLVMOrcMaterializationUnitRef mu;
@@ -1230,7 +1244,11 @@ llvm_create_jit_instance(LLVMTargetMachineRef tm)
* Symbol resolution support for "special" functions, e.g. a call into an
* SQL callable function.
*/
+#if LLVM_VERSION_MAJOR > 14
+ ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL, NULL);
+#else
ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
+#endif
LLVMOrcJITDylibAddGenerator(LLVMOrcLLJITGetMainJITDylib(lljit), ref_gen);
return lljit;
--
2.37.3.542.gdd3f6c4cae
Hi,
On 2022-10-03 12:16:12 -0700, Andres Freund wrote:
I haven't yet run through the whole regression test with an assert enabled
llvm because an assert-enabled llvm is *SLOW*, but it got through the first
few parallel groups ok. Using an optimized llvm 15, all tests pass with
PGOPTIONS=-cjit_above_cost=0.
That did pass. But to be able to use clang >= 15 one more piece is
needed. Updated patch attached.
Greetings,
Andres Freund
Attachments:
v2-0001-WIP-jit-LLVM-15-Minimal-changes.patchtext/x-diff; charset=us-asciiDownload
From 0fed706031df781bb5889a859c47379e3c37f4f4 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 22 Sep 2022 23:38:56 +1200
Subject: [PATCH v2] WIP: jit: LLVM 15: Minimal changes.
Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque
pointers still exists and we can request that on our context. We have
until LLVM 16 to move to opaque pointers.
---
src/backend/jit/llvm/llvmjit.c | 18 +++++++
src/backend/jit/llvm/meson.build | 3 ++
configure | 89 ++++++++++++++++++++++++++++++++
configure.ac | 3 ++
4 files changed, 113 insertions(+)
diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c
index fd3eecf27d3..bccfcfa9698 100644
--- a/src/backend/jit/llvm/llvmjit.c
+++ b/src/backend/jit/llvm/llvmjit.c
@@ -798,6 +798,16 @@ llvm_session_initialize(void)
LLVMInitializeNativeAsmPrinter();
LLVMInitializeNativeAsmParser();
+ /*
+ * When targetting an llvm version with opaque pointers enabled by
+ * default, turn them off for the context we build our code in. Don't need
+ * to do so for other contexts (e.g. llvm_ts_context) - once the IR is
+ * generated, it carries the necessary information.
+ */
+#if LLVM_VERSION_MAJOR > 14
+ LLVMContextSetOpaquePointers(LLVMGetGlobalContext(), false);
+#endif
+
/*
* Synchronize types early, as that also includes inferring the target
* triple.
@@ -1112,7 +1122,11 @@ llvm_resolve_symbols(LLVMOrcDefinitionGeneratorRef GeneratorObj, void *Ctx,
LLVMOrcJITDylibRef JD, LLVMOrcJITDylibLookupFlags JDLookupFlags,
LLVMOrcCLookupSet LookupSet, size_t LookupSetSize)
{
+#if LLVM_VERSION_MAJOR > 14
+ LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMOrcCSymbolMapPair) * LookupSetSize);
+#else
LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);
+#endif
LLVMErrorRef error;
LLVMOrcMaterializationUnitRef mu;
@@ -1230,7 +1244,11 @@ llvm_create_jit_instance(LLVMTargetMachineRef tm)
* Symbol resolution support for "special" functions, e.g. a call into an
* SQL callable function.
*/
+#if LLVM_VERSION_MAJOR > 14
+ ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL, NULL);
+#else
ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
+#endif
LLVMOrcJITDylibAddGenerator(LLVMOrcLLJITGetMainJITDylib(lljit), ref_gen);
return lljit;
diff --git a/src/backend/jit/llvm/meson.build b/src/backend/jit/llvm/meson.build
index de2e624ab58..e5a702163b7 100644
--- a/src/backend/jit/llvm/meson.build
+++ b/src/backend/jit/llvm/meson.build
@@ -51,6 +51,9 @@ endif
# XXX: Need to determine proper version of the function cflags for clang
bitcode_cflags = ['-fno-strict-aliasing', '-fwrapv']
+if llvm.version().version_compare('>=15.0')
+ bitcode_cflags += ['-Xclang', '-no-opaque-pointers']
+endif
bitcode_cflags += cppflags
# XXX: Worth improving on the logic to find directories here
diff --git a/configure b/configure
index 1caca21b625..cf457a0ed4a 100755
--- a/configure
+++ b/configure
@@ -7391,6 +7391,95 @@ if test x"$pgac_cv_prog_CLANGXX_cxxflags__fexcess_precision_standard" = x"yes";
fi
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CLANG} supports -Xclang -no-opaque-pointers, for BITCODE_CFLAGS" >&5
+$as_echo_n "checking whether ${CLANG} supports -Xclang -no-opaque-pointers, for BITCODE_CFLAGS... " >&6; }
+if ${pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CLANG}
+CFLAGS="${BITCODE_CFLAGS} -Xclang -no-opaque-pointers"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers=yes
+else
+ pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers" >&5
+$as_echo "$pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers" >&6; }
+if test x"$pgac_cv_prog_CLANG_cflags__Xclang__no_opaque_pointers" = x"yes"; then
+ BITCODE_CFLAGS="${BITCODE_CFLAGS} -Xclang -no-opaque-pointers"
+fi
+
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CLANGXX} supports -Xclang -no-opaque-pointers, for BITCODE_CXXFLAGS" >&5
+$as_echo_n "checking whether ${CLANGXX} supports -Xclang -no-opaque-pointers, for BITCODE_CXXFLAGS... " >&6; }
+if ${pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CXXFLAGS=$CXXFLAGS
+pgac_save_CXX=$CXX
+CXX=${CLANGXX}
+CXXFLAGS="${BITCODE_CXXFLAGS} -Xclang -no-opaque-pointers"
+ac_save_cxx_werror_flag=$ac_cxx_werror_flag
+ac_cxx_werror_flag=yes
+ac_ext=cpp
+ac_cpp='$CXXCPP $CPPFLAGS'
+ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+ pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers=yes
+else
+ pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ac_cxx_werror_flag=$ac_save_cxx_werror_flag
+CXXFLAGS="$pgac_save_CXXFLAGS"
+CXX="$pgac_save_CXX"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers" >&5
+$as_echo "$pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers" >&6; }
+if test x"$pgac_cv_prog_CLANGXX_cxxflags__Xclang__no_opaque_pointers" = x"yes"; then
+ BITCODE_CXXFLAGS="${BITCODE_CXXFLAGS} -Xclang -no-opaque-pointers"
+fi
+
+
NOT_THE_CFLAGS=""
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CLANG} supports -Wunused-command-line-argument, for NOT_THE_CFLAGS" >&5
$as_echo_n "checking whether ${CLANG} supports -Wunused-command-line-argument, for NOT_THE_CFLAGS... " >&6; }
diff --git a/configure.ac b/configure.ac
index 10fa55dd154..ecc6c495db9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -625,6 +625,9 @@ if test "$with_llvm" = yes ; then
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fexcess-precision=standard])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-fexcess-precision=standard])
+ PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-Xclang -no-opaque-pointers])
+ PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-Xclang -no-opaque-pointers])
+
NOT_THE_CFLAGS=""
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wunused-command-line-argument])
if test -n "$NOT_THE_CFLAGS"; then
--
2.37.3.542.gdd3f6c4cae
On Mon, Oct 3, 2022 at 2:41 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2022-10-03 12:16:12 -0700, Andres Freund wrote:
I haven't yet run through the whole regression test with an assert
enabled
llvm because an assert-enabled llvm is *SLOW*, but it got through the
first
few parallel groups ok. Using an optimized llvm 15, all tests pass with
PGOPTIONS=-cjit_above_cost=0.That did pass. But to be able to use clang >= 15 one more piece is
needed. Updated patch attached.Greetings,
Andres Freund
Hi,
+ * When targetting an llvm version with opaque pointers enabled by
I think `targetting` should be spelled as targeting
Cheers
On Tue, Oct 4, 2022 at 10:45 AM Zhihong Yu <zyu@yugabyte.com> wrote:
On Mon, Oct 3, 2022 at 2:41 PM Andres Freund <andres@anarazel.de> wrote:
On 2022-10-03 12:16:12 -0700, Andres Freund wrote:
I haven't yet run through the whole regression test with an assert enabled
llvm because an assert-enabled llvm is *SLOW*, but it got through the first
few parallel groups ok. Using an optimized llvm 15, all tests pass with
PGOPTIONS=-cjit_above_cost=0.
+ /*
+ * When targetting an llvm version with opaque pointers enabled by
+ * default, turn them off for the context we build our code in. Don't need
+ * to do so for other contexts (e.g. llvm_ts_context) - once the IR is
+ * generated, it carries the necessary information.
+ */
+#if LLVM_VERSION_MAJOR > 14
+ LLVMContextSetOpaquePointers(LLVMGetGlobalContext(), false);
+#endifAhh, right, thanks!
That did pass. But to be able to use clang >= 15 one more piece is
needed. Updated patch attached.
+ bitcode_cflags += ['-Xclang', '-no-opaque-pointers']
Oh, right. That makes sense.
I think `targetting` should be spelled as targeting
Yeah.
OK, I'll wait for the dust to settle on our 15 release and then
back-patch this. Then I'll keep working on the opaque pointer support
for master, which LLVM 16 will need (I expect we'll eventually want to
back-patch that eventually, but first things first...).
Hi Thomas,
On Tue, 2022-10-11 at 11:07 +1300, Thomas Munro wrote:
OK, I'll wait for the dust to settle on our 15 release and then
back-patch this. Then I'll keep working on the opaque pointer
support for master, which LLVM 16 will need (I expect we'll
eventually want to back-patch that eventually, but first things
first...).
Fedora 37 is out very very soon, and ships with CLANG/LLVM 15. What is
the timeline for backpatching llvm15 support?
Thanks!
Cheers,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On Tue, Oct 18, 2022 at 10:01 PM Devrim Gündüz <devrim@gunduz.org> wrote:
On Tue, 2022-10-11 at 11:07 +1300, Thomas Munro wrote:
OK, I'll wait for the dust to settle on our 15 release and then
back-patch this. Then I'll keep working on the opaque pointer
support for master, which LLVM 16 will need (I expect we'll
eventually want to back-patch that eventually, but first things
first...).Fedora 37 is out very very soon, and ships with CLANG/LLVM 15. What is
the timeline for backpatching llvm15 support?
Hi Devrim,
Will do first thing tomorrow.
Hi,
On Tue, 2022-10-18 at 22:06 +1300, Thomas Munro wrote:
Will do first thing tomorrow.
Just wanted to confirm that I pushed Fedora RPMs built against LLVM 15
by adding these patches.
Thanks Thomas.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On Wed, Oct 26, 2022 at 4:28 AM Devrim Gündüz <devrim@gunduz.org> wrote:
On Tue, 2022-10-18 at 22:06 +1300, Thomas Munro wrote:
Will do first thing tomorrow.
Just wanted to confirm that I pushed Fedora RPMs built against LLVM 15
by adding these patches.Thanks Thomas.
Cool.
FTR I still have to finish the 'real' fixes for LLVM 16. Their
cadence is one major release every 6 months, putting it at about April
'23, but I'll try to get it ready quite soon on our master branch. BF
animal seawasp is green again for now, but I expect it will turn back
to red pretty soon when they start ripping out the deprecated stuff on
their master branch...