Re: JIT compiling with LLVM v12.2

Hi,

On 2018-03-22 10:09:23 +1300, Thomas Munro wrote:
> > FWIW, a 32bit chroot, on a 64bit kernel works:
> >
> > 2018-03-21 20:57:56.576 UTC [3708] DEBUG: successfully loaded LLVM in current session
> > 2018-03-21 20:57:56.577 UTC [3708] DEBUG: JIT detected CPU "skylake", with features "+sse2,+cx16,-tbm,-avx512ifma,-avx512dq,-fma4,+prfchw,+bmi2,+xsavec,+fsgsbase,+popcnt,+aes,-pcommit,+xsaves,-avx512er,-clwb,-avx512f,-pku,+smap,+mmx,-xop,+rdseed,+hle,-sse4a,-avx512bw,+clflushopt,+xsave,-avx512vl,+invpcid,-avx512cd,+avx,+rtm,+fma,+bmi,-mwaitx,+rdrnd,+sse4.1,+sse4.2,+avx2,+sse,+lzcnt,+pclmul,-prefetchwt1,+f16c,+ssse3,+sgx,+cmov,-avx512vbmi,+movbe,+xsaveopt,-sha,+adx,-avx512pf,+sse3"
> > 2018-03-21 20:57:56.579 UTC [3708] DEBUG: time to inline: 0.000s, opt: 0.000s, emit: 0.002s
> >
> > that's debian testing though.
>
> Hmm. So now I'm doing this:

I've now reproduced this. It actually only fails for *some*
queries, a good number works. Investigating.

As a random aside, our costing is fairly ridiculous here:
┌──────────────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├──────────────────────────────────────────────────────────────────────────────┤
│ Sort (cost=1088314.21..1103119.40 rows=5922075 width=34) │
│ Sort Key: booltbl1.f1, booltbl2.f1 │
│ -> Nested Loop (cost=0.00..118524.73 rows=5922075 width=34) │
│ Join Filter: ((booltbl2.f1 = booltbl1.f1) OR booltbl1.f1) │
│ -> Seq Scan on booltbl1 (cost=0.00..38.10 rows=2810 width=1) │
│ -> Materialize (cost=0.00..52.15 rows=2810 width=1) │
│ -> Seq Scan on booltbl2 (cost=0.00..38.10 rows=2810 width=1) │
│ JIT: │
│ Functions: 6 │
│ Inlining: true │
│ Optimization: true │
└──────────────────────────────────────────────────────────────────────────────┘

> I wonder what I'm doing wrong... what you're doing is very similar,
> right? It's a 32 bit user land on a 64 bit kernel whereas mine is a
> 32 bit user land on a 32 bit kernel (on a 64 bit CPU).

I think it's I that did something wrong not you. And the architecture
thing is a non-issue, because we're taking the target triple from the
right place. I think it's a separate issue. Notably the generated code
is apparently corrupt, when reading in the generated bitcode:

$ opt-6.0 -O3 -S < /tmp/data/6814.1.bc|less
opt-6.0: <stdin>: error: Invalid record (Producer: 'LLVM6.0.0' Reader: 'LLVM 6.0.0')

I suspect there's a 32bit vs 64bit confusion in the expression code
somewhere, might've accidentally used a 64bit type for Datum somewhere
or such. Will compile an LLVM with assertions enabled, to figure this
out (which verifies this kinda thing).

Greetings,

Andres Freund