[llvm-dev] [RFC] Lanai backend

[James Y Knight via llvm-dev]

It'd be be super-exciting if everyone working on random LLVM backends
pushed their targets upstream, and then did their development on ToT! If
this proposal would catalyze other organizations to submit their backends
upstream as well, that would seem like a huge win.

I'd expect the benefit of having developers of such targets all working
upstream to very much outweigh the usually minor cost of updating it for
other codegen changes.

That only holds as long as there *is* an active maintainer, of course. If a
target actually becomes deadweight, it should be removed as soon as
possible.

On Tue, Feb 9, 2016 at 5:37 PM, Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > 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.
>
> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/98885b06/attachment.html>