[llvm-dev] [RFC] Lanai backend

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Chris Lattner via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Jacques Pienaar" <jpienaar at google.com>
> Cc: llvm-dev at lists.llvm.org
> Sent: Tuesday, February 9, 2016 4:37:18 PM
> Subject: Re: [llvm-dev] [RFC] Lanai backend
> 
> 
> > On Feb 9, 2016, at 9:40 AM, Jacques Pienaar via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > 
> > Hi all,
> > 
> > We would like to contribute a new backend for the Lanai processor
> > (derived from the processor described in [1]).
> 
> Hi Jacques,
> 
> We generally have a low bar for accepting new “experimental”
> backends, but I think that this is the first proposal to add a
> target for a hardware that general LLVM contributors can’t have
> access to.  As such, we’ll have to figure out as a community whether
> this makes sense.
> 
> Here are the tradeoffs I see of accepting the backend:
> 
> 1) I imagine that there is a big win for you, not having to merge
> with mainline.  Maintaining an out of tree backend is a pain :-)
> 
> 2) For the community, this is probably a net loss since changes to
> common codegen could would be required to update your backend, but
> no one else in the community would benefit from the target being in
> mainline.

In my experience, updating backend code to deal with API changes, etc. is a much smaller problem than trying to update updating regression tests to account for changes in common code. As a result, making sure that the regression tests are well written (use regular expressions instead of hard-coded register numbers, CHECK-DAG, etc. where appropriate), and documented to make clear what is being tested is very important.

That having been said, the regression tests are, in a sense, the most valuable contribution a backend like this makes. They'll test the common codegen code in configurations not hit by the other backends (yet!), and the more of that the better. Plus, the more regression tests we have, the better self hosting becomes as a test on all targets ;)

> 
> 3) There is probably a small but non-zero benefit to keeping your
> team working directly on mainline, since you’re more likely to do
> ancillary work in ToT.  If your development is in mainline, this
> work is most likely to go into llvm.org instead of into your local
> branch.

This really depends on the development philosophy adopted by the backend maintainers. If code that *should* be common code is put up for review and properly integrated into the common infrastructure, then it can be a big win. I've not yet met a backend for real hardware that did not require at least some common codegen enhancement to function well, and these enhancements often end up helping at least some other targets. If, on the other hand, deficiencies in the common codegen are just hacked around in the backend, or enhancements otherwise live only there, the value to the community will be much smaller.

At this point, I trust Google to do the right thing here.

 -Hal

> 
> 4) There could be an educational benefit of having the backend,
> particularly if it has unique challenges to overcome.
> 
> 
> What do others think about this?  I know that several organizations
> have not even bothered proposing internal-only targets for inclusion
> in llvm.org, since they would effectively be contributing dead code
> that the community would have to maintain.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory