Re: JIT compiling with LLVM v12.2 - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: JIT compiling with LLVM v12.2
Date
Msg-id CAEepm=39F_B3Ou8S3OrUw+hJEUP3p=wCu0ug-TTW67qKN53g3w@mail.gmail.com
Whole thread Raw
In response to Re: JIT compiling with LLVM v12.2  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: JIT compiling with LLVM v12.2  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> I've now run out of things to complain about for now.  Nice work!

I jumped on a POWER8 box.  As expected, the same breakage occurs.  So
I hacked LLVM 6.0 thusly:

diff --git a/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
b/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
index 68397be..08aa3a8 100644
--- a/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
+++ b/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
@@ -54,7 +54,11 @@ createLocalCompileCallbackManager(const Triple &T,
 std::function<std::unique_ptr<IndirectStubsManager>()>
 createLocalIndirectStubsManagerBuilder(const Triple &T) {
   switch (T.getArch()) {
-    default: return nullptr;
+    default:
+      return [](){
+        return llvm::make_unique<
+                       orc::LocalIndirectStubsManager<orc::OrcGenericABI>>();
+      };

     case Triple::aarch64:
       return [](){

I am not qualified to have an opinion on whether this is the correct
fix for LLVM, but with this change our make check passes, indicating
that things are otherwise looking good on this architecture.

So I've now tested your branch on various combinations of:
FreeBSD/amd64 (including with a weird CPU that lacks AVX),
Debian/amd64, Debian/i386, Debian/arm64, RHEL/ppc64le, macOS/amd64,
with LLVM 3.9, 4,0, 5.0, 6.0, with GCC and clang as the main compiler,
with libstdc++ and libc++ as the C++ standard library.

If I had access to one I'd try it on a big endian machine, but I
don't.  Anyone?  The elephant in the room is Windows.  I'm not
personally in the same room as that particular elephant, however.

FWIW, your branch doesn't build against LLVM master (future 7.0),
because the shared module stuff is changing:

llvmjit.c: In function ‘llvm_compile_module’:
llvmjit.c:544:4: error: unknown type name ‘LLVMSharedModuleRef’
    LLVMSharedModuleRef smod;
    ^
llvmjit.c:546:4: warning: implicit declaration of function
‘LLVMOrcMakeSharedModule’ [-Wimplicit-function-declaration]
    smod = LLVMOrcMakeSharedModule(context->module);
    ^
llvmjit.c:548:12: warning: passing argument 3 of
‘LLVMOrcAddEagerlyCompiledIR’ makes pointer from integer without a
cast [enabled by default]
            llvm_resolve_symbol, NULL))
            ^
In file included from llvmjit.c:31:0:
/home/thomas.munro/build/llvm/debug/install/include/llvm-c/OrcBindings.h:99:1:
note: expected ‘LLVMModuleRef’ but argument is of type ‘int’
 LLVMOrcAddEagerlyCompiledIR(LLVMOrcJITStackRef JITStack,
 ^
llvmjit.c:552:4: warning: implicit declaration of function
‘LLVMOrcDisposeSharedModuleRef’ [-Wimplicit-function-declaration]
    LLVMOrcDisposeSharedModuleRef(smod);
    ^

--
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Boolean partitions syntax
Next
From: Tom Lane
Date:
Subject: Re: Multiple-output-file make rules: We're Doing It Wrong