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

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 ;)

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.

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).

-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/20150604/5a675066/attachment.html>

Sorry for the mistake. I noticed that clang-query was complaining about missing
build commands in the BPF target. After investigating it and finding that
enabling it didn't break things, I concluded that someone had forgotten the
cmake build as occasionally happens and thought it was an obvious fix.

One small suggestion to avoid this in the future: When an experimental target is
added, could we make it policy to mention experimental targets in a comment next
to the default target list.

FWIW, buildbot hasn't sent me any significant failures from the commit. Just
three transient failures on the ppc64le buildbots and one more on
sanitizer-x86_64-linux-autoconf.
________________________________________
From: Eric Christopher [echristo at gmail.com]
Sent: 04 June 2015 23:52
To: Alexei Starovoitov; Daniel Sanders; Chandler Carruth; llvmdev at
cs.uiuc.edu; Renato Golin
Cc: llvm-commits
Subject: Re: [llvm] r239035 - Include BPF target in CMake builds.

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.

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).

-eric

On Thu, Jun 4, 2015 at 2:38 PM Alexei Starovoitov <alexei.starovoitov at
gmail.com<mailto:alexei.starovoitov at gmail.com>> wrote:
On Thu, Jun 4, 2015 at 5:51 AM, Daniel Sanders
<daniel.sanders at imgtec.com<mailto: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 ;)