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
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 |