Re: JIT compiling with LLVM v11

Hi,

On 2018-03-02 19:13:01 -0500, Peter Eisentraut wrote:
> On 3/1/18 03:02, Andres Freund wrote:
> > I've pushed a revised version of my JIT patchset.
> > The git tree is at
> > https://git.postgresql.org/git/users/andresfreund/postgres.git
> > in the jit branch
> > https://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/jit
>
> (testing 2e15e8b8100a61ec092a1e5b2db4a93f07a64cbd)
>
> I'm having an interesting time getting this to build on macOS.

Sorry for that...

> First, you need to use a CXX that is reasonably similar to the CC.
> Otherwise, the CXX will complain about things like attributes not
> being supported etc. That's not surprising, but it's a support issue
> that we'll have to prepare ourselves for.

Right.

> 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++'
>
> That comes from llvm-config --cxxflags, which was apparently made for
> /usr/bin/cc (which is clang).

> I see here the same problems as we had in the olden days with Perl,
> where it gave us a bunch of compiler flags that applied to the system
> compiler but not the compiler currently in use. We should just take the
> flags that we really need, like -I and -L. Maybe we don't need it at all.

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.

> Using this patch gets it past that:
>
> diff --git a/src/backend/jit/llvm/llvmjit_inline.cpp
> b/src/backend/jit/llvm/llvmjit_inline.cpp
> index d4204d2cd2..ad87cfd2d9 100644
> --- a/src/backend/jit/llvm/llvmjit_inline.cpp
> +++ b/src/backend/jit/llvm/llvmjit_inline.cpp
> @@ -22,7 +22,6 @@
> extern "C"
> {
> #include "postgres.h"
> -#include "jit/llvmjit.h"
>
> #include <fcntl.h>
> #include <sys/mman.h>
> @@ -35,6 +34,8 @@ extern "C"
> #include "storage/fd.h"
> }
>
> +#include "jit/llvmjit.h"
> +
> #include <llvm-c/Core.h>
> #include <llvm-c/BitReader.h>
>
> 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?

> Then, I'm getting this error:

> It seems the problem here is linking C++ with the C compiler. If I
> hack in to use c++ in the above command, it continues, and the build
> completes.

Yea, I was afraid of that, even if I didn't see it locally.
Unfortunately Makefile.shlib has a bunch of references both to
$(COMPILER) and $(CC). Most of the relevant platforms (using llvmjit on
hpux seems like and edge case somebody desiring it can fix) use
$(COMPILER).

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.

> 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.

> So, how do I turn this on then? I see a bunch of new GUC settings
> that are all off by default. Which ones turn the feature(s) on?

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

If you set -c log_min_messages=debug one and run a query you'd see
something like:
2018-03-02 16:27:19.717 PST [11077][3/8] DEBUG: time to inline: 0.087s
2018-03-02 16:27:19.724 PST [11077][3/8] DEBUG: time to opt: 0.007s
2018-03-02 16:27:19.750 PST [11077][3/8] DEBUG: time to emit: 0.027s

I think I should just remove jit_tuple_deforming=1,
jit_perform_inlining=1, they're better done via the cost settings (-1
disables). I think having -c jit_expressions is helpful leaving the
cost settings aside, because it allows to enable/disable jitting
wholesale without changing cost settings, which seems good.

Greetings,

Andres Freund