upcoming API changes for LLVM 12

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

upcoming API changes for LLVM 12

Andres Freund
Hi,

There will be a breaking API change for JIT related API in LLVM
12. Mostly about making control over various aspects easier, and then
building on top of that providing new features (like JIT compiling in
the background and making it easier to share JIT compiled output between
processes).

I've worked with Lang Hames to ensure that the new C API has feature
parity...

The postgres changes are fairly localized, all in llvmjit.c - it's just
a few #ifdefs to support both LLVM 12 and before.

The two questions I have are:

1) Which versions do we want to add LLVM 12 support?  It'd be fairly
   easy to backport all the way. But it's not quite a bugfix... OTOH,
   it'd probably painful for packagers to have dependencies on different
   versions of LLVM for different versions of postgres.

2) When do we want to add LLVM 12 support? PG will soon stop compiling
   against LLVM 12, which will be released in about 6 months. I worked
   with Lang to make most of the breaking changes in a branch (to be
   merged in the next few days), but it's possible that there will be a
   few smaller changes.

I'd be inclined to add support for LLVM 12 to master soon, and then
backpatch that support around LLVM 12's release.

Comments?

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Thomas Munro-5
On Fri, Oct 16, 2020 at 2:12 PM Andres Freund <[hidden email]> wrote:
> There will be a breaking API change for JIT related API in LLVM
> 12. Mostly about making control over various aspects easier, and then
> building on top of that providing new features (like JIT compiling in
> the background and making it easier to share JIT compiled output between
> processes).
>
> I've worked with Lang Hames to ensure that the new C API has feature
> parity...

Cool!

> I'd be inclined to add support for LLVM 12 to master soon, and then
> backpatch that support around LLVM 12's release.

+1.  I guess Fabien's animal "seawasp" will turn red next week.
Apparently it rebuilds bleeding edge LLVM weekly (though strangely
last week it went backwards... huh).


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Álvaro Herrera
In reply to this post by Andres Freund
On 2020-Oct-15, Andres Freund wrote:

> There will be a breaking API change for JIT related API in LLVM
> 12. Mostly about making control over various aspects easier, and then
> building on top of that providing new features (like JIT compiling in
> the background and making it easier to share JIT compiled output between
> processes).
>
> I've worked with Lang Hames to ensure that the new C API has feature
> parity...

Whee, sounds pretty good ... (am I dreaming too much if I hope execution
starts with non-jitted and switches on the fly to jitted once
background compilation finishes?)

> 2) When do we want to add LLVM 12 support? PG will soon stop compiling
>    against LLVM 12, which will be released in about 6 months. I worked
>    with Lang to make most of the breaking changes in a branch (to be
>    merged in the next few days), but it's possible that there will be a
>    few smaller changes.

hmm, how regular are LLVM releases?  I mean, what if pg14 ends up being
released sooner than LLVM12 – would there be a problem?


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Andres Freund
Hi,

On 2020-10-16 02:45:51 -0300, Alvaro Herrera wrote:
> Whee, sounds pretty good ... (am I dreaming too much if I hope
> execution starts with non-jitted and switches on the fly to jitted
> once background compilation finishes?)

There's some more work needed to get there, but yes, the basics for that
are there now. It'd perhaps be doable with threads now, but it's not
clear we want that... We probably could build it with processes too -
it'd require some memory management fun, but it's doable.


> > 2) When do we want to add LLVM 12 support? PG will soon stop compiling
> >    against LLVM 12, which will be released in about 6 months. I worked
> >    with Lang to make most of the breaking changes in a branch (to be
> >    merged in the next few days), but it's possible that there will be a
> >    few smaller changes.
>
> hmm, how regular are LLVM releases?  I mean, what if pg14 ends up being
> released sooner than LLVM12 – would there be a problem?

Pretty unlikely - they're half yearly releases, and come out on a
somewhat regular schedule. They've moved a few weeks but not more. And
even if they did - having a few #ifdefs for LLVM 12 would be ok anyway.

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Tom Lane-2
Andres Freund <[hidden email]> writes:
> On 2020-10-16 02:45:51 -0300, Alvaro Herrera wrote:
>>> 2) When do we want to add LLVM 12 support? PG will soon stop compiling
>>> against LLVM 12, which will be released in about 6 months. I worked
>>> with Lang to make most of the breaking changes in a branch (to be
>>> merged in the next few days), but it's possible that there will be a
>>> few smaller changes.

>> hmm, how regular are LLVM releases?  I mean, what if pg14 ends up being
>> released sooner than LLVM12 – would there be a problem?

> Pretty unlikely - they're half yearly releases, and come out on a
> somewhat regular schedule. They've moved a few weeks but not more. And
> even if they did - having a few #ifdefs for LLVM 12 would be ok anyway.

Yeah.  As long as we're not breaking the ability to build against older
LLVM, I can't see a reason not to apply and back-patch these changes.
We usually want all supported PG versions to build against newer tool
chains, and this seems to fall into that category.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Andres Freund
Hi,

On 2020-10-16 10:22:57 -0400, Tom Lane wrote:
> Yeah.  As long as we're not breaking the ability to build against older
> LLVM, I can't see a reason not to apply and back-patch these changes.
> We usually want all supported PG versions to build against newer tool
> chains, and this seems to fall into that category.

Cool! I just ran that branch against 3.9 (the currently oldest supported
version), and that still works.


A related question is whether it'd be time to prune the oldest supported
LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
release, was 2016-12-13). There's currently no *pressing* reason to
reduce it, but it is the cause of few #ifdefs - but more importantly it
increases the test matrix.

I'm inclined to just have a deterministic policy that we apply around
release time going forward. E.g. don't support versions that are newer
than the newest available LLVM version in the second newest
long-term-supported distribution release of RHEL, Ubuntu, Debian?

Regards,

Andres


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Tom Lane-2
Andres Freund <[hidden email]> writes:
> A related question is whether it'd be time to prune the oldest supported
> LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
> release, was 2016-12-13). There's currently no *pressing* reason to
> reduce it, but it is the cause of few #ifdefs - but more importantly it
> increases the test matrix.

> I'm inclined to just have a deterministic policy that we apply around
> release time going forward. E.g. don't support versions that are newer
> than the newest available LLVM version in the second newest
> long-term-supported distribution release of RHEL, Ubuntu, Debian?

Meh.  I do not think these should be mechanistic one-size-fits-all
decisions.  A lot hinges on just how messy it is to continue support
for a given tool.  Moreover, the policy you propose above is
completely out of line with our approach to every other toolchain
we use.

I'd rather see an approach along the lines of "it's time to drop
support for LLVM version X because it can't do Y", rather than
"... because Z amount of time has passed".

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Álvaro Herrera
In reply to this post by Andres Freund
On 2020-Oct-16, Andres Freund wrote:

> A related question is whether it'd be time to prune the oldest supported
> LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
> release, was 2016-12-13). There's currently no *pressing* reason to
> reduce it, but it is the cause of few #ifdefs - but more importantly it
> increases the test matrix.

Is there a matrix of LLVM versions supported by live distros?  It sounds
like pruning away 3.9 from branch master would be reasonable enough;
OTOH looking at the current LLVM support code in Postgres it doesn't
look like you would actually save all that much.  Maybe the picture
changes with things you're doing now, but it's not evident from what's
in the tree now.

> I'm inclined to just have a deterministic policy that we apply around
> release time going forward. E.g. don't support versions that are newer
> than the newest available LLVM version in the second newest
> long-term-supported distribution release of RHEL, Ubuntu, Debian?

It seems fair to think that new Postgres releases should be put in
production only with the newest LTS release of each OS -- no need to go
back to the second newest.  But I think we should use such a criteria to
drive discussion rather than as a battle axe chopping stuff away.


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Jesse Zhang
In reply to this post by Andres Freund
Hi Andres,

On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <[hidden email]> wrote:

>
> Hi,
>
> There will be a breaking API change for JIT related API in LLVM
> 12. Mostly about making control over various aspects easier, and then
> building on top of that providing new features (like JIT compiling in
> the background and making it easier to share JIT compiled output between
> processes).
>
> I've worked with Lang Hames to ensure that the new C API has feature
> parity...
>

I assume you're alluding to the removal of ORC legacy (v1) API? How far
back was feature parity in the new API, or we could only switch starting
with LLVM 12?

> The postgres changes are fairly localized, all in llvmjit.c - it's just
> a few #ifdefs to support both LLVM 12 and before.
>
> The two questions I have are:
>
> 1) Which versions do we want to add LLVM 12 support?  It'd be fairly
>    easy to backport all the way. But it's not quite a bugfix... OTOH,
>    it'd probably painful for packagers to have dependencies on different
>    versions of LLVM for different versions of postgres.
>
> 2) When do we want to add LLVM 12 support? PG will soon stop compiling
>    against LLVM 12, which will be released in about 6 months. I worked
>    with Lang to make most of the breaking changes in a branch (to be
>    merged in the next few days), but it's possible that there will be a
>    few smaller changes.

I think this has already happened about two weeks ago when Lang's commit
6154c4115cd4b78d landed in LLVM master.

Cheers,
Jesse


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Andres Freund
Hi,

On 2020-11-02 10:28:33 -0800, Jesse Zhang wrote:

> On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <[hidden email]> wrote:
> > There will be a breaking API change for JIT related API in LLVM
> > 12. Mostly about making control over various aspects easier, and then
> > building on top of that providing new features (like JIT compiling in
> > the background and making it easier to share JIT compiled output between
> > processes).
> >
> > I've worked with Lang Hames to ensure that the new C API has feature
> > parity...
> >
>
> I assume you're alluding to the removal of ORC legacy (v1) API?

Yes.


> How far back was feature parity in the new API, or we could only switch starting
> with LLVM 12?

Parity is in 12 only - I had to work with Lang for a while to get to
parity. There really is no reason to switch earlier anyway.


> > The postgres changes are fairly localized, all in llvmjit.c - it's just
> > a few #ifdefs to support both LLVM 12 and before.
> >
> > The two questions I have are:
> >
> > 1) Which versions do we want to add LLVM 12 support?  It'd be fairly
> >    easy to backport all the way. But it's not quite a bugfix... OTOH,
> >    it'd probably painful for packagers to have dependencies on different
> >    versions of LLVM for different versions of postgres.
> >
> > 2) When do we want to add LLVM 12 support? PG will soon stop compiling
> >    against LLVM 12, which will be released in about 6 months. I worked
> >    with Lang to make most of the breaking changes in a branch (to be
> >    merged in the next few days), but it's possible that there will be a
> >    few smaller changes.
>
> I think this has already happened about two weeks ago when Lang's commit
> 6154c4115cd4b78d landed in LLVM master.

Yea, I just need to polish the support a bit more. Shouldn't be too
much more work (right now it has too much unnecessary duplication, need
to split some reindation out into a separate commit).

https://github.com/anarazel/postgres/commits/llvm-12

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Tom Lane-2
Andres Freund <[hidden email]> writes:
> On 2020-11-02 10:28:33 -0800, Jesse Zhang wrote:
>> On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <[hidden email]> wrote:
>>> There will be a breaking API change for JIT related API in LLVM
>>> 12.

seawasp, which runs some bleeding-edge version of clang, has been falling
over for the last couple of weeks:

/home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2  -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -D_DEBUG -D_GNU_SOURCE -I/home/fabien/clgtk/include  -I../../../../src/include  -D_GNU_SOURCE -I/usr/include/libxml2  -flto=thin -emit-llvm -c -o llvmjit_types.bc llvmjit_types.c
llvmjit.c:21:10: fatal error: 'llvm-c/OrcBindings.h' file not found
#include <llvm-c/OrcBindings.h>
         ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.

I suppose this is related to what you are talking about here.
If so, could we prioritize getting that committed?  It's annoying
to have the buildfarm failures page so full of this one issue.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Andres Freund
Hi,

On 2020-11-08 17:35:20 -0500, Tom Lane wrote:
> I suppose this is related to what you are talking about here.

Yes.


> If so, could we prioritize getting that committed?  It's annoying
> to have the buildfarm failures page so full of this one issue.

Yea, I'll try to do that in the next few days (was plannin to last week,
but due to a hand injury I was typing one handed last week - makes it
pretty annoying to clean up code. But I just started being able to at
least use my left thumb again...).

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Tom Lane-2
Andres Freund <[hidden email]> writes:
> Yea, I'll try to do that in the next few days (was plannin to last week,
> but due to a hand injury I was typing one handed last week - makes it
> pretty annoying to clean up code. But I just started being able to at
> least use my left thumb again...).

Ouch.  Get well soon, and don't overstress your hand --- that's a
good recipe for long-term problems.

                        regards, tom lane


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Andres Freund
Hi,

On 2020-11-08 18:22:50 -0500, Tom Lane wrote:
> Andres Freund <[hidden email]> writes:
> > Yea, I'll try to do that in the next few days

I pushed the change to master. If that doesn't show any problems, I'll
backpatch in a week or so. Seawasp runs only on master, so it should
satisfy the buildfarm at least.


> > (was plannin to last week,
> > but due to a hand injury I was typing one handed last week - makes it
> > pretty annoying to clean up code. But I just started being able to at
> > least use my left thumb again...).
>
> Ouch.  Get well soon, and don't overstress your hand --- that's a
> good recipe for long-term problems.

Thanks! I *am* planning not to write all that much for a while. But it's
frustrating / hard, as many other activities are even less an option...

Greetings,

Andres Freund


Reply | Threaded
Open this post in threaded view
|

Re: upcoming API changes for LLVM 12

Tom Lane-2
Andres Freund <[hidden email]> writes:
> I pushed the change to master.

Thanks!

> If that doesn't show any problems, I'll
> backpatch in a week or so. Seawasp runs only on master, so it should
> satisfy the buildfarm at least.

Yeah, sounds like a good plan.  FWIW, master builds clean for me.

                        regards, tom lane