[LLVMdev] [llvm-commits] RFC: LLVM incubation, or requirements for committing new backends

[Sean Silva]

I imagine that the linux kernel development process has a similar
issue with adding new architectures since the parallels are pretty
significant (incremental development, time-based releases, etc.). It
might be a huge win for one of the more senior community members to
inquire on the LKML about how this similar problem is handled in their
community, whether there is anything that LLVM is currently doing that
"didn't work" for them, and general advice.

--Sean Silva

On Tue, Jul 17, 2012 at 10:06 AM, Owen Anderson <resistor at mac.com> wrote:
> Michah,
>
> On Jul 17, 2012, at 7:53 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote:
>
>> Owen/Chandler/etc..,
>> While I have no issue with having a more complete and documented method of submitting backends, the problem is the barrier to entry for some backends is being significantly raised, where they did not exist in the past. In the past AMD has reported issues that we have found from internal development to LLVM, along with patches in some cases. Some have been fixed, but others are unique to our backends and still are not in mainline. Many times the response to attempts to get them fixed has been to get the backend in the mainline development tree first. Now that we are finally able to push our backends out publicly, we are getting pushback that we need to contribute in other places first. While I completely agree with 4 of the five points below, the requirement that we contribute to core for things that are outside the scope of the backend seems overly onerous. Tom's AMDGPU backend is not the only backend AMD would like to push into mainline, as our production AMDIL backend is!
>   in the pipeline to be added and AMD has announced that the HSA foundations compiler will also be open sourced(which is a third backend from AMD, plus more, see http://www.phoronix.com/scan.php?page=news_item&px=MTEyMzQ). I would just hate to see these get delayed because of barriers to entry that seem artificial or out of scope of the proposed/required changes.
>>
>> So I guess the issue is, what else is required to the backends to make them acceptable for LLVM.
>
> My biggest issue with most contributed backends that run into trouble is a process issue, not a technical one.  Technical problems can be corrected over time, but process problems create new technical problems going forward.
>
> LLVM is developed in an incremental method.  All work happens on mainline, in small, incremental steps, and all backends must work all of the time.  However, many backend contributions come in the form on code drops.  This completely at odds with the incremental method, and leads to technical problems: bad decisions that could have been pointed out and fixed early in development (if it were done incrementally) have become so baked in that they can't realistically be changed, and become blockers for integration into mainline.
>
> That said, stuff happens, and I understand that lots of backends cannot be developed incrementally from the get-go.  I would still consider a code-drop'd backend for integration if the developers demonstrated that they're willing to work with the LLVM process going forward.  That means practicing incremental development going forward.  This is exactly the case where I think an incubation system would be valuable: it gives backends that were developed in a non-LLVM-ish way a chance to transition with LLVM-style development over a period of time, without having to get a complete sign-off at the time of the initial code drop.
>
> --Owen
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits