[llvm-dev] [RFC] Lanai backend

Hal Finkel via llvm-dev
Wed, 10 Feb 2016 00:02:59 -0000

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