Thread: upcoming API changes for LLVM 12
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
On Fri, Oct 16, 2020 at 2:12 PM Andres Freund <andres@anarazel.de> 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).
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?
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
Andres Freund <andres@anarazel.de> 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
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
Andres Freund <andres@anarazel.de> 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
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.
Hi Andres, On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <andres@anarazel.de> 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
Hi, On 2020-11-02 10:28:33 -0800, Jesse Zhang wrote: > On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <andres@anarazel.de> 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
Andres Freund <andres@anarazel.de> writes:
> On 2020-11-02 10:28:33 -0800, Jesse Zhang wrote:
>> On Thu, Oct 15, 2020 at 6:12 PM Andres Freund <andres@anarazel.de> 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
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
Andres Freund <andres@anarazel.de> 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
Hi, On 2020-11-08 18:22:50 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> 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
Andres Freund <andres@anarazel.de> 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
Hi, On 2020-11-09 20:13:43 -0800, Andres Freund wrote: > 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. It was a bit longer than a week, but I finally have done so... Let's see what the world^Wbuildfarm says. - Andres