From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: JIT compiling with LLVM v9.0 |
Date: | 2018-02-02 05:22:34 |
Message-ID: | CAEepm=2phgttxxKrigiQQd7eVft7n2XaVZTFvqDb1H-F+UuB1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 2, 2018 at 5:11 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> Another small thing which might be environmental... llvmjit_types.bc
> is getting installed into ${prefix}/lib here, but you're looking for
> it in ${prefix}/lib/postgresql:
Is there something broken about my installation? I see simple
arithmetic expressions apparently compiling and working but I can
easily find stuff that breaks... so far I think it's anything
involving string literals:
postgres=# set jit_above_cost = 0;
SET
postgres=# select quote_ident('x');
ERROR: failed to resolve name MakeExpandedObjectReadOnlyInternal
Well actually just select 'hello world' does it. I've attached a backtrace.
Tab completion is broken for me with jit_above_cost = 0 due to
tab-complete.c queries failing with various other errors including:
set <tab>:
ERROR: failed to resolve name ExecEvalScalarArrayOp
update <tab>:
ERROR: failed to resolve name quote_ident
show <tab>:
ERROR: failed to resolve name slot_getsomeattrs
I wasn't sure from your status message how much of this is expected at
this stage...
This is built from:
commit 302b7a284d30fb0e00eb5f0163aa933d4d9bea10 (HEAD -> jit, andresfreund/jit)
... plus the extern "C" tweak I posted earlier to make my clang 4.0
compiler happy, built on a FreeBSD 11.1 box with:
./configure --prefix=/home/munro/install/ --enable-tap-tests
--enable-cassert --enable-debug --enable-depend --with-llvm CC="ccache
cc" CXX="ccache c++" CXXFLAGS="-std=c++11"
LLVM_CONFIG=/usr/local/llvm50/bin/llvm-config
--with-libraries="/usr/local/lib" --with-includes="/usr/local/include"
The clang that was used for bitcode was the system /usr/bin/clang,
version 4.0. Is it a problem that I used that for compiling the
bitcode, but LLVM5 for JIT? I actually tried
CLANG=/usr/local/llvm50/bin/clang but ran into weird failures I
haven't got to the bottom of at ThinLink time so I couldn't get as far
as a running system.
I installed llvm50 from a package. I did need to make a tiny tweak by
hand: in src/Makefile.global, llvm-config --system-libs had said
-l/usr/lib/libexecinfo.so which wasn't linking and looks wrong to me
so I changed it to -lexecinfo, noted that it worked and reported a bug
upstream: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225621
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
backtrace.txt | text/plain | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-02-02 05:39:28 | Re: proposal: alternative psql commands quit and exit |
Previous Message | Michael Paquier | 2018-02-02 05:06:50 | Re: [HACKERS] Creating backup history files for backups taken from standbys |