Re: JIT compiling with LLVM v9.0

From: Pierre Ducroquet <pierre(dot)ducroquet(at)people-doc(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: JIT compiling with LLVM v9.0
Date: 2018-01-29 10:20:38
Message-ID: 28630226.ItCLzQd8kL@pierred-pdoc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM
> > documentation is really lacking when it comes to porting from version x
> > to x+1.
> > The only really missing part I found is that in 3.9, GlobalValueSummary
> > has no flag showing if it's not EligibleToImport. I am not sure about the
> > consequences.
>
> I think that'd not be too bad, it'd just lead to some small increase in
> overhead as more modules would be loaded.
>
> > BTW, the makefile for src/backend/lib does not remove the llvmjit_types.bc
> > file when cleaning, and doesn't seem to install in the right folder.
>
> Hm, both seems to be right here? Note that the llvmjit_types.bc file
> should *not* go into the bitcode/ directory, as it's about syncing types
> not inlining. I've added a comment to that effect.

The file was installed in lib/ while the code expected it in lib/postgresql.
So there was something wrong here.
And deleting the file when cleaning is needed if at configure another llvm
version is used. The file must be generated with a clang release that is not
more recent than the llvm version linked to postgresql. Otherwise, the bitcode
generated is not accepted by llvm.

Regards

Pierre

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-01-29 10:23:48 Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions
Previous Message David Rowley 2018-01-29 10:12:43 Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?