llvm dev - Jun 2015 - [LLVMdev] [llvm] r239035 - Include BPF target in CMake builds.

On Thu, Jun 4, 2015 at 3:52 PM, Eric Christopher <echristo at gmail.com>
wrote:
> You were correct in your earlier assumption, this shouldn't have been
added
> by default yet.
>
> I'm going to go ahead and revert this patch in a bit unless someone
tells me
> not to bother, and you can propose your patch to do, essentially, the same
> thing with the rationale from this message if you'd like.
of course. consider it proposed.
llvmdev was cc-ed already.
> FWIW I'm not against it, you've been an active maintainer and the
BPF port
> hasn't been terrible to update (from looking at the patches) or keep
updated
> (in the few occasions I've done it).
Great.
> -eric
>
> On Thu, Jun 4, 2015 at 2:38 PM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
>>
>> On Thu, Jun 4, 2015 at 5:51 AM, Daniel Sanders
>> <daniel.sanders at imgtec.com> wrote:
>> > Author: dsanders
>> > Date: Thu Jun  4 07:51:20 2015
>> > New Revision: 239035
>> >
>> > Include BPF target in CMake builds.
>> >
>> > Modified:
>> >     llvm/trunk/CMakeLists.txt
>> >
>> > --- llvm/trunk/CMakeLists.txt (original)
>> > +++ llvm/trunk/CMakeLists.txt Thu Jun  4 07:51:20 2015
>> > @@ -169,6 +169,7 @@ set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BIN
>> >  set(LLVM_ALL_TARGETS
>> >    AArch64
>> >    ARM
>> > +  BPF
>> >    CppBackend
>>
>> wow :)
>> this is what I wanted to propose for the last few months.
>> I had a chat with Chandler about graduating BPF backend
>> from experimental, but I want to make sure everyone is ok
>> before proceeding.
>> Current status of it:
>> - running on x64, arm64, s390 architectures
>> - projects that use it: perf, tc, ovs
>> - there are few front-ends in the works:
>>  one is translating language X to C and then using clang/llvm,
>>  another is generating llvm IR directly,
>>  yet another is using clang rewriter to augment C language
>>  for tracing/networking needs.
>>  one project tried to hack clang overall and was abandoned.
>> - I've seen people embedding binary llc with bpf support
>>  in their github projects.
>> - broken llvm build with bpf backend was reported many
>>  times with few folks even provided simple patches to unbreak it.
>> - we've started to prepare buildbot specific to bpf, but hit
>>  configuration issues with zorg. Hopefully it will be functional soon.
>> - as far as I can see all across the board api refactoring that
>>  was done by a bunch of people over the last 5 month
>>  didn't cause any problems for them or for the backend
>>
>> bpf backend has been in-tree since January and has enough
>> users, so I think it's time to graduate it from experimental.
>> Honestly I was surprised to see this patch... I was hoping
>> it will be my honors to do it ;)

On Thu, Jun 4, 2015 at 4:09 PM Alexei Starovoitov <
alexei.starovoitov at gmail.com> wrote:
> On Thu, Jun 4, 2015 at 3:52 PM, Eric Christopher <echristo at
gmail.com>
> wrote:
> > You were correct in your earlier assumption, this shouldn't have
been
> added
> > by default yet.
> >
> > I'm going to go ahead and revert this patch in a bit unless
someone
> tells me
> > not to bother, and you can propose your patch to do, essentially, the
> same
> > thing with the rationale from this message if you'd like.
>
> of course. consider it proposed.
> llvmdev was cc-ed already.
>
>
Probably best to have a new email with a subject of "Make BPF
non-experimental" or some such to make it more obvious to people reading
the list.

Thanks and sorry for the extra work here :)

-eric

> > FWIW I'm not against it, you've been an active maintainer and
the BPF
> port
> > hasn't been terrible to update (from looking at the patches) or
keep
> updated
> > (in the few occasions I've done it).
>
> Great.
>
> > -eric
> >
> > On Thu, Jun 4, 2015 at 2:38 PM Alexei Starovoitov
> > <alexei.starovoitov at gmail.com> wrote:
> >>
> >> On Thu, Jun 4, 2015 at 5:51 AM, Daniel Sanders
> >> <daniel.sanders at imgtec.com> wrote:
> >> > Author: dsanders
> >> > Date: Thu Jun  4 07:51:20 2015
> >> > New Revision: 239035
> >> >
> >> > Include BPF target in CMake builds.
> >> >
> >> > Modified:
> >> >     llvm/trunk/CMakeLists.txt
> >> >
> >> > --- llvm/trunk/CMakeLists.txt (original)
> >> > +++ llvm/trunk/CMakeLists.txt Thu Jun  4 07:51:20 2015
> >> > @@ -169,6 +169,7 @@ set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BIN
> >> >  set(LLVM_ALL_TARGETS
> >> >    AArch64
> >> >    ARM
> >> > +  BPF
> >> >    CppBackend
> >>
> >> wow :)
> >> this is what I wanted to propose for the last few months.
> >> I had a chat with Chandler about graduating BPF backend
> >> from experimental, but I want to make sure everyone is ok
> >> before proceeding.
> >> Current status of it:
> >> - running on x64, arm64, s390 architectures
> >> - projects that use it: perf, tc, ovs
> >> - there are few front-ends in the works:
> >>  one is translating language X to C and then using clang/llvm,
> >>  another is generating llvm IR directly,
> >>  yet another is using clang rewriter to augment C language
> >>  for tracing/networking needs.
> >>  one project tried to hack clang overall and was abandoned.
> >> - I've seen people embedding binary llc with bpf support
> >>  in their github projects.
> >> - broken llvm build with bpf backend was reported many
> >>  times with few folks even provided simple patches to unbreak it.
> >> - we've started to prepare buildbot specific to bpf, but hit
> >>  configuration issues with zorg. Hopefully it will be functional
soon.
> >> - as far as I can see all across the board api refactoring that
> >>  was done by a bunch of people over the last 5 month
> >>  didn't cause any problems for them or for the backend
> >>
> >> bpf backend has been in-tree since January and has enough
> >> users, so I think it's time to graduate it from experimental.
> >> Honestly I was surprised to see this patch... I was hoping
> >> it will be my honors to do it ;)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150605/c3d00e27/attachment.html>