Hi, On 2018-03-03 09:37:35 -0500, Peter Eisentraut wrote: > 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.
Well, some -f obtions are ABI / behaviour influencing. You can't, to my knowledge, mix/match code build with -fno-rtti with code built with it (influences symbol names). LLVM builds without rtti by default, but a lot of distros enable it... I narrowed the filter to -std= (from -std), which should take care of the -stdlib bit. I also dropped -fno-exceptions being copied since that should not conflict. > >> 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? ;-) Heh, done ;). Let's see how long it takes... > > 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. Cool. > >> 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? I've submitted them upstream, but they're not yet released. > > 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. Yup, as discussed in the earlier reply to you, I decided it's not particularly useful to have. As also threatened in that reply, I've switched the defaults so you shouldn't have to change them anymore. > If I turn on either of the first two, then make installcheck fails. See > attached diff. Hm, so there's definitely something going on here that I don't yet understand. I've pushed something that I've a slight hunch about (dropping the dots from the symbol names, some tooling doesn't seem to like that). I'd to rebase to fix a few issues, but I've left the changes made since the last push as separate commits. Could you run something like: regression[18425][1]=# set jit_above_cost = 0; SET regression[18425][1]=# set client_min_messages=debug2; SET regression[18425][1]=# SELECT pg_jit_available(); DEBUG: 00000: probing availability of llvm for JIT at /home/andres/build/postgres/dev-assert/install/lib/llvmjit.so LOCATION: provider_init, jit.c:83 DEBUG: 00000: successfully loaded LLVM in current session LOCATION: provider_init, jit.c:107 DEBUG: 00000: time to opt: 0.001s LOCATION: llvm_compile_module, llvmjit.c:435 DEBUG: 00000: time to emit: 0.014s LOCATION: llvm_compile_module, llvmjit.c:481 ┌──────────────────┐ │ pg_jit_available │ ├──────────────────┤ │ t │ └──────────────────┘ (1 row) regression[18425][1]=# select now(); DEBUG: 00000: time to opt: 0.001s LOCATION: llvm_compile_module, llvmjit.c:435 DEBUG: 00000: time to emit: 0.008s LOCATION: llvm_compile_module, llvmjit.c:481 ┌───────────────────────────────┐ │ now │ ├───────────────────────────────┤ │ 2018-03-03 11:33:13.776947-08 │ └───────────────────────────────┘ (1 row) regression[18425][1]=# SET jit_dump_bitcode = 1; SET regression[18425][1]=# select now(); DEBUG: 00000: time to opt: 0.002s LOCATION: llvm_compile_module, llvmjit.c:435 DEBUG: 00000: time to emit: 0.018s LOCATION: llvm_compile_module, llvmjit.c:481 ┌───────────────────────────────┐ │ now │ ├───────────────────────────────┤ │ 2018-03-03 11:33:23.508875-08 │ └───────────────────────────────┘ (1 row) The last command should have dumped something into your data directory, even if it failed like your regression test output showed. Could attach the two files something like ls -lstr /srv/dev/pgdev-dev/*.b would show if /srv/dev/pgdev-dev/ is your test directory? If my random hunch or this doesn't bear fruit, I'm going to have to get access to an OSX machine somehow :( Independent of this, I'm working to make the code pgindent compliant. Given the typical coding patterns when emitting IR (nested function calls) that's painful because pgindent insists on indenting everything a lot. I've started adding a few small wrapper functions to make that bearable... Greetings, Andres Freund
