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-21 10:10:27
Message-ID: CAEepm=0HqkxWk2w8N2nXQXC_43Mucn-v=8QdY8vOG5ojo9kJRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Indeed. I've pushed a rebased version now, that basically just fixes the
>> issue Thomas observed.
>
> I set up a 32 bit i386 virtual machine and installed Debian 9.4.

Next up, I have an arm64 system running Debian 9.4. It bombs in
"make check" and in simple tests:

postgres=# set jit_above_cost = 0;
SET
postgres=# select 42;
<boom>

The stack looks like this:

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x0000ffff8f65adf4 in __GI_abort () at abort.c:89
#2 0x0000ffff83e2de40 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#3 0x0000ffff83e2bd4c in ?? () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#4 0x0000ffff83e2bd98 in std::terminate() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#5 0x0000ffff83e2c01c in __cxa_throw () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#6 0x0000ffff83e544bc in std::__throw_bad_function_call() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#7 0x0000ffff85176a2c in LLVMOrcCreateInstance () from
/usr/lib/aarch64-linux-gnu/libLLVM-3.9.so.1
#8 0x0000ffff865c4db0 in llvm_session_initialize () at llvmjit.c:643
#9 llvm_create_context (jitFlags=9) at llvmjit.c:136
#10 0x0000ffff865cf8c8 in llvm_compile_expr (state=0xaaaaf2300208) at
llvmjit_expr.c:132
#11 0x0000aaaab64ca71c in ExecReadyExpr
(state=state(at)entry=0xaaaaf2300208) at execExpr.c:627
#12 0x0000aaaab64cd7b8 in ExecBuildProjectionInfo
(targetList=<optimized out>, econtext=<optimized out>, slot=<optimized
out>, parent=parent(at)entry=0xaaaaf22ffde0,
inputDesc=inputDesc(at)entry=0x0)
at execExpr.c:471
#13 0x0000aaaab64e0028 in ExecAssignProjectionInfo
(planstate=planstate(at)entry=0xaaaaf22ffde0,
inputDesc=inputDesc(at)entry=0x0) at execUtils.c:460
#14 0x0000aaaab64fca28 in ExecInitResult
(node=node(at)entry=0xaaaaf224e1a0, estate=estate(at)entry=0xaaaaf22ffbc8,
eflags=eflags(at)entry=16) at nodeResult.c:221
#15 0x0000aaaab64db828 in ExecInitNode (node=0xaaaaf224e1a0,
node(at)entry=0xaaaaf227a610, estate=estate(at)entry=0xaaaaf22ffbc8,
eflags=eflags(at)entry=16) at execProcnode.c:164
#16 0x0000aaaab64d6a70 in InitPlan (eflags=16,
queryDesc=0xaaaaf226d808) at execMain.c:1051
#17 standard_ExecutorStart (queryDesc=0xaaaaf226d808, eflags=16) at
execMain.c:266
#18 0x0000aaaab662dbec in PortalStart (portal=0x400,
portal(at)entry=0xaaaaf22b04d8, params=0x59004077f060bc65,
params(at)entry=0x0, eflags=43690, eflags(at)entry=0,
snapshot=0xaaaab689df58, snapshot(at)entry=0x0)
at pquery.c:520
#19 0x0000aaaab6628b18 in exec_simple_query
(query_string=query_string(at)entry=0xaaaaf224c3d8 "select 42;") at
postgres.c:1082
#20 0x0000aaaab662a6a8 in PostgresMain (argc=<optimized out>,
argv=argv(at)entry=0xaaaaf2278b70, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4147
#21 0x0000aaaab631cdd0 in BackendRun (port=0xaaaaf226d410) at postmaster.c:4409
#22 BackendStartup (port=0xaaaaf226d410) at postmaster.c:4081
#23 ServerLoop () at postmaster.c:1754
#24 0x0000aaaab65ab048 in PostmasterMain (argc=<optimized out>,
argv=<optimized out>) at postmaster.c:1362
#25 0x0000aaaab631e7cc in main (argc=3, argv=0xaaaaf2246f70) at main.c:228

Taking frame 6 at face value, it appears to be trying to call an empty
std::function (that's what the exception std::bad_function_call
means). No clue how or why though.

With LLVM 5.0 (from backports) it seemed to get further (?):

Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x0000ffffa9642df4 in __GI_abort () at abort.c:89
#2 0x0000ffff9d306e40 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#3 0x0000ffff9d304d4c in ?? () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#4 0x0000ffff9d304d98 in std::terminate() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#5 0x0000ffff9d30501c in __cxa_throw () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#6 0x0000ffff9d32d4bc in std::__throw_bad_function_call() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#7 0x0000ffff9eac7dc4 in ?? () from /usr/lib/aarch64-linux-gnu/libLLVM-5.0.so.1
#8 0x0000aaaadd2dced0 in ?? ()
#9 0x0000000040100401 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Configure was run like this:

./configure \
--prefix=$HOME/install \
--enable-cassert \
--enable-debug \
--with-llvm \
CC="ccache gcc" \
CXX="ccache g++" \
CLANG="ccache /usr/lib/llvm-3.9/bin/clang" \
LLVM_CONFIG="/usr/lib/llvm-3.9/bin/llvm-config"

I can provide access to this thing if you think that'd be useful.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emre Hasegeli 2018-03-21 10:22:03 Re: constraint exclusion and nulls in IN (..) clause
Previous Message Arthur Zakirov 2018-03-21 09:00:52 Re: [PROPOSAL] Shared Ispell dictionaries