Horton

Re: JIT compiling with LLVM v11

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Pierre Ducroquet <p.psql@pinaraf.info>
Date: 2018-03-03T14:37:35Z
Lists: pgsql-hackers

Attachments

On 3/2/18 19:29, Andres Freund wrote:
>> Using my standard set of CC=gcc-7 and CXX=g++-7, the build fails with
>>
>> g++-7: error: unrecognized command line option '-stdlib=libc++'

> It's actually already filtered, I just added -std*, because of selecting
> the c++ standard, I guess I need to filter more aggressively.  This is
> fairly fairly annoying.

I see you already filter llvm-config --cflags by picking only -I and -D.
 Why not do the same for --cxxflags?  Any other options that we need
like -f* should be discovered using the normal
does-the-compiler-support-this-option tests.

>> It seems that it was intended that way anyway, since llvmjit.h contains
>> its own provisions for extern C.
> 
> Hrmpf, yea, I broke that the third time now.  I'm actually inclined to
> add an appropriate #ifdef ... #error so it's not repeated, what do you
> think?

Not sure.  Why not just move the line and not move it again? ;-)

> Does putting an
> override COMPILER = $(CXX) $(CFLAGS)
> 
> into src/backend/jit/llvm/Makefile work?  It does force the use of CXX
> for all important platforms if I see it correctly. Verified that it
> works on linux.

Your latest HEAD builds out of the box for me now using the system compiler.

>> configure didn't find any of the LLVMOrc* symbols it was looking for.
>> Is that a problem?  They seem to be for some debugging support.
> 
> That's not a problem, except that the symbols won't be registered with
> the debugger, which is a bit annoying for backtraces. I tried to have
> configure throw errors in cases llvm is too old or such.

Where does one get those then?  I have LLVM 5.0.1.  Is there something
even newer?

> Hm, I'll switch them on in the development branch. Independent of the
> final decision that's definitely the right thing for now.  The "full
> capability" of the patchset is used if you turn on these three GUCs:
> 
> -c jit_expressions=1
> -c jit_tuple_deforming=1
> -c jit_perform_inlining=1

The last one doesn't seem to exist anymore.

If I turn on either of the first two, then make installcheck fails.  See
attached diff.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Improve JIT docs.

  2. Add documentation for the JIT feature.

  3. Add EXPLAIN support for JIT.

  4. Add inlining support to LLVM JIT provider.

  5. JIT tuple deforming in LLVM JIT provider.

  6. Add FIELDNO_* macro designating offset into structs required for JIT.

  7. Add expression compilation support to LLVM JIT provider.

  8. Expand list of synchronized types and functions in LLVM JIT provider.

  9. Add helpers for emitting LLVM IR.

  10. Basic planner and executor integration for JIT.

  11. Debugging and profiling support for LLVM JIT provider.

  12. Support for optimizing and emitting code in LLVM JIT provider.

  13. Add file containing extensions of the LLVM C API.

  14. Basic JIT provider and error handling infrastructure.

  15. Add configure infrastructure (--with-llvm) to enable LLVM support.

  16. Add C++ support to configure.

  17. Add PGAC_PROG_VARCC_VARFLAGS_OPT autoconf macro.

  18. Fix VM buffer pin management in heap_lock_updated_tuple_rec().

  19. Allow tupleslots to have a fixed tupledesc, use in executor nodes.

  20. Expression evaluation based aggregate transition invocation.

  21. Perform slot validity checks in a separate pass over expression.

  22. Rely on executor utils to build targetlist for DML RETURNING.

  23. Refer to OS X as "macOS", except for the port name which is still "darwin".