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

[Villmow, Micah]

Yeah, in these cases, we did not have the authority to submit our backends
until relatively recently(last December was when legal/code approval
 finally came through).

So like I mentioned in the other email, the bottleneck is getting the
code into the public, from that point on, we can work on conforming to
the LLVM style. I agree with the incubation style approach, that could
solve these issues.


Micah
> -----Original Message-----
> From: Owen Anderson [mailto:resistor at mac.com]
> Sent: Tuesday, July 17, 2012 10:06 AM
> To: Villmow, Micah
> Cc: Stellard, Thomas; llvm-commits at cs.uiuc.edu LLVM; LLVM at dcs-
> maillist.cs.uiuc.edu; Developers Mailing List
> Subject: Re: [LLVMdev] [llvm-commits] RFC: LLVM incubation, or
> requirements for committing new backends
> 
> 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