From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info> |
Subject: | Re: JIT compiling with LLVM v11 |
Date: | 2018-03-15 02:56:52 |
Message-ID: | 20180315025652.2f2roophwgz2tbqx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-03-14 22:36:52 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> >> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> >>> It looks
> >>> like -fexcess-precision-standard is coming from a configure test that
> >>> was run against ${CC}, not against ${CLANG}, so I hacked the generated
> >>> src/Makefile.global to remove that too, just to see if I could get
> >>> past that.
>
> >> Yea, I'd hoped we could avoid duplicating all the configure tests, but
> >> maybe not :(.
>
> > I've mostly done that now (not pushed). I've created new
> > PGAC_PROG_VARCC_VARFLAGS_OPT(compiler variable, flag variable, testflag)
> > function, which now is used to implement PGAC_PROG_CC_CFLAGS_OPT and
> > PGAC_PROG_CC_VAR_OPT (similar for CXX). That makes it reasonable to
> > test the variables clang recognizes separately.
>
> Meh.
Why? The necessary configure code isn't that large:
# Test for behaviour changing compiler flags, to keep compatibility
# with compiler used for normal postgres code. XXX expand
if test "$with_llvm" = yes ; then
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fno-strict-aliasing])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fwrapv])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fexcess-precision=standard])
AC_SUBST(BITCODE_CFLAGS, $BITCODE_CFLAGS)
fi
If the relevant clang version doesn't understand, say
-fno-strict-aliasing, then we'd in trouble already if it's
required. After all we do support compiling postgres with clang.
> I agree with Thomas' concern that it's not clear we can or should
> just ignore discrepancies between the -f options supported by the C
> and CLANG compilers.
What's the precise concern here? We pass these flags to work around
compiler issues / "defining our standard". As I said above, if we do not
know the right flags to make clang behave sensibly, we're in trouble
already.
For a good part of the code we already want to be compatible with
compiling postgres with one compiler, and linking to libraries compiled
with something else.
> Is it really so necessary to bring a second compiler into the mix for
> this? Why not just insist that JIT is only supported if the main build
> is done with clang, too? My experience with mixing results from different
> compilers is, eh, not positive.
I don't like that option. It doesn't really buy us much, a few lines of
config code, and one additional configure option that should normally be
autodected from the environment. Requiring a specific compiler will be
terrible on windows, seems out of line how we do development, requires
using clang which is still generates a bit slower code, prevent getting
gcc warnings etc.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2018-03-15 03:32:39 | Re: Incorrect comment for ExecProcessReturning |
Previous Message | Tom Lane | 2018-03-15 02:53:12 | Re: Re: [GSOC 18] Performance Farm Project——Initialization Project |