Re: JIT compiling with LLVM v11

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: 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 00:20:17
Message-ID: 20180315002017.ekyjsa7rqfr6yspc@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-03-13 15:29:33 -0700, Andres Freund wrote:
> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote:
> > I decided to try this on a CentOS 7.2 box. It has LLVM 3.9 in the
> > 'epel' package repo, but unfortunately it only has clang 3.4.
>
> That's a bit odd, given llvm and clang really live in the same repo...

I don't really live in the RHEL world, but I wonder if
https://developers.redhat.com/blog/2017/10/04/red-hat-adds-go-clangllvm-rust-compiler-toolsets-updates-gcc/
is relevant?
Appears to be available on centos too
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/

I checked it out and supporting 3.4 would be a bit painful due to not
being able to directly emit module summaries. We could support that by
building the summaries separately using LLVM, but that'd be either
slower for everyone, or we'd need somewhat finnicky conditionals.

> > clang: error: unknown argument: '-fexcess-precision=standard'
> > clang: error: unknown argument: '-flto=thin'
> >
> > Ok, so I hacked src/Makefile.global.in to remove -flto=thin.
>
> I think I can get actually rid of that entirely.

Err, no, not really. Would increase overhead due to separate module
summary generation, so I'd rather not do it.

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

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-03-15 00:31:19 Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Previous Message Thomas Munro 2018-03-15 00:03:55 Re: neqjoinsel versus "refresh materialized view concurrently"