[PATCH] [v5] BPF backend

Alexei Starovoitov alexei.starovoitov at gmail.com
Tue Jan 13 22:32:41 PST 2015

On Tue, Jan 13, 2015 at 7:18 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Tue, Jan 13, 2015 at 3:09 PM, Tom Stellard <tom at stellard.net> wrote:
>> On Tue, Jan 13, 2015 at 03:09:09PM +0000, Renato Golin wrote:
>> > On 12 January 2015 at 21:07, Alexei Starovoitov
>> > <alexei.starovoitov at gmail.com> wrote:
>> > > I'm still not sure who suppose to approve it.
>> >
>> > Used to be Chris, though it may have changed.
>> >
>> > If not, I think if Chandler, Eric, Anton, Tom and others are happy
>> > with, it should be fine, no?
>> >
>> There's not a well defined process for adding a new backend, so
>> usually it ends up being Chris who gives the final approval.  FWIW,
>> I thinks this is OK to merge.
> I think historically Evan has actually been more involved in shepherding new
> backends into LLVM.
> However, I don't think there is any reason to hold up a new backend if there
> are multiple active contributors to backends and the common code generator
> who are happy with this addition and none of the active maintainers speaking
> up against it or with specific concerns.
> (I'd like a chance to glance through the code a bit myself before given
> explicit support, but will do so soon)

thanks! Appreciate it. Will wait for your feedback.

> FWIW, I think that once you have a few active backend maintainers who are
> explicitly supportive, you should just start a *new* thread on llvmdev (so
> it doesn't get lost with the others) and say "Heads up, BPF backend review
> is coming to a close over on llvm-commits <link to thread>. It will be
> landing sometime next week. Just want folks to have a chance to post any
> comments if they haven't already".

As far as next 6 months or so...
Today I don't feel confident to commit the changes
without pre-review by somebody more experienced in the whole
backend machinery. Like Tom, for example :)
So will appreciate review for the rest of the changes
that I'm planning to make in the future.
As I mentioned this patch set is a solid base that usable
as it is, but we'll continue working on improving code
generation and extra features.
Fortunately prior experience from llvm 3.2+ showed
trivial maintenance efforts, so day-to-day this backend
won't be causing any headaches.
On the kernel side quite a few folks are waiting for it
to land to start playing with it more actively.
And three different companies are planning to write
front-ends... so a lot more to come in the future.

More information about the llvm-commits mailing list