Re: JIT compiling with LLVM v9.0

Hi,

On 2018-01-24 22:35:08 +0100, Pierre Ducroquet wrote:
> I tried to build on Debian sid, using GCC 7 and LLVM 5. I used the following
> to compile, using your branch @3195c2821d :

Thanks!

> $ export LLVM_CONFIG=/usr/bin/llvm-config-5.0
> $ ./configure --with-llvm
> $ make
>
> And I had the following build error :
> llvmjit_wrap.cpp:32:10: fatal error: llvm-c/DebugInfo.h: No such file or
> directory
> #include "llvm-c/DebugInfo.h"
> ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
>
> In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as a C
> ++ API in llvm/IR/DebugInfo.h.

Hm, I compiled against 5.0 quite recently, but added the stripping of
debuginfo lateron. I'll add a fallback method, thanks for pointing that
out!

> But I still could not build because the LLVM API changed between 5.0 and 6.0
> regarding value info SummaryList.

Hm, thought these changes were from before my 5.0 test. But the code
evolved heavily, so I might misremember. Let me see.

Thanks, I'll try to push fixes into the tree soon-ish..

> I'm not sure how to test everything properly, so the patch is attached for
> both these issues, do as you wish with it… :)

What I do for testing is running postgres' tests against a started
server that has all cost based behaviour turned off (which makes no
sense from a runtime optimization perspective, but increases
coverage...).

The flags I pass to the server are:
-c jit_expressions=1 -c jit_tuple_deforming=1 -c jit_perform_inlining=1 -c jit_above_cost=0 -c jit_optimize_above_cost=0
then I run
make -s installcheck-parallel
to see whether things pass. The flags makes the tests slow-ish, but
tests everything under jit. In particular errors.sql's recursion check
takes a while...

Obviously none of the standard tests are interesting from a performance
perspective...

FWIW, here's an shortened excerpt of the debugging output of TPCH query:

DEBUG: checking inlinability of ExecAggInitGroup
DEBUG: considering extern function datumCopy at 75 for inlining
DEBUG: inline top function ExecAggInitGroup total_instcount: 24, partial: 21

so the inliner found a reference to ExecAggInitGroup, inlined it, and
scheduled to checkout datumCopy, externally referenced from
ExecAggInitGroup, later.

DEBUG: uneligible to import errstart due to early threshold: 150 vs 37

elog stuff wasn't inlined because errstart has 150 insn, but at this
point the limit was 37 (aka 150 / 2 / 2). Early means this was decided
based on the summary. There's also 'late' checks preventing inlining if
dependencies of the inlined variable (local static functions, constant
static global variables) make it bigger than the summary knows about.

Then we get to execute the importing:
DEBUG: performing import of postgres/utils/fmgr/fmgr.bc pg_detoast_datum, pg_detoast_datum_packed
DEBUG: performing import of postgres/utils/adt/arrayfuncs.bc construct_array
DEBUG: performing import of postgres/utils/error/assert.bc ExceptionalCondition, .str.1, .str
DEBUG: performing import of postgres/utils/adt/expandeddatum.bc EOH_flatten_into, DeleteExpandedObject, .str.1, .str.2, .str.4, EOH_get_flat_size
DEBUG: performing import of postgres/utils/adt/int8.bc __func__.overflowerr, .str, .str.12, int8inc, overflowerr, pg_add_s64_overflow
...
DEBUG: performing import of postgres/utils/adt/date.bc date_le_timestamp, date2timestamp, .str, __func__.date2timestamp, .str.26

And there's a timing summary (debugging build)
DEBUG: time to inline: 0.145s
DEBUG: time to opt: 0.156s
DEBUG: time to emit: 0.078s

Same debugging build:

tpch_10[6930][1]=# set jit_expressions = 1;
tpch_10[6930][1]=# \i ~/tmp/tpch/pg-tpch/queries/q01.sql
...
Time: 28442.870 ms (00:28.443)

tpch_10[6930][1]=# set jit_expressions = 0;
tpch_10[6930][1]=# \i ~/tmp/tpch/pg-tpch/queries/q01.sql
...
Time: 70357.830 ms (01:10.358)
tpch_10[6930][1]=# show max_parallel_workers_per_gather;
┌─────────────────────────────────┐
│ max_parallel_workers_per_gather │
├─────────────────────────────────┤
│ 0 │
└─────────────────────────────────┘

Now admittedly a debugging/assertion enabled build isn't quite a fair
fight, but it's not that much smaller a win without that.

- Andres