Re: JIT compiling with LLVM v12.2 - Mailing list pgsql-hackers

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