Re: JIT compiling with LLVM v12.2

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JIT compiling with LLVM v12.2
Date: 2018-03-22 03:09:51
Message-ID: CAEepm=39F_B3Ou8S3OrUw+hJEUP3p=wCu0ug-TTW67qKN53g3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-22 03:16:22 Re: Multiple-output-file make rules: We're Doing It Wrong
Previous Message Amit Langote 2018-03-22 02:59:07 Re: Boolean partitions syntax