[llvm-dev] [RFC] Lanai backend

[David Blaikie via llvm-dev]

On Wed, Feb 10, 2016 at 3:40 AM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 10 February 2016 at 06:44, Chandler Carruth via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > But I also see another option, which someone else mentioned up-thread:
> > simply make only the regression tests be supported. Without a regression
> > test case that exhibits a bug, no reverts or other complaints. It would
> be
> > entirely up to the maintainer to find and reduce such test cases from any
> > failure of execution tests out-of-tree.
>
> IMHO, it's about transparency and commitment.
>
> For experimental back-ends (like BPF), what you describe is perfectly
> fine. If we wanted BPF to be official, I'd personally only accept it
> if there was at least one buildbot with a minimal domain-specific set
> of tests.


Why would that be a requirement for you?


> In the BPF case, I'd expect a Linux booting and running some
> arbitrary code expecting a certain result. In a hardware-simile, like
> your back-end, I'd expect some generic code to be compiled and run
> successfully, strongly biased to getting the test-suite running on it.
>
> If we make this official (and I agree that by far this is a highly
> theoretical point), it means people will start to use and report bugs,

and not all bugs can be reduced to a FileCheck. If, OTOH, Google is to
> be the only user of this back-end *ever*, then I don't see *any*
> reason to move this in-tree other than "saving Google some time",
> which is not very sporting.
>

I think Chris Lattner enumerated some valuable points regarding the benefit
of having a backend in-tree even if it's never intended for use outside a
select group.

"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.orginstead of into your local branch.

4) There could be an educational benefit of having the backend,
particularly if it has unique challenges to overcome."

>
> There is a big difference, in my view, between a "technology preview"
> and a "cost-cutting decision".


Cutting costs isn't inherently bad - we all strive for efficiency. The
question is if it's the wrong tradeoff (if the wrong groups end up paying
for it, or the overall cost is higher, etc).


> Most companies contributing to LLVM
> wouldn't care, and they could even contribute their own secret
> back-ends to LLVM as a result of it, but my personal and very strong
> opinion is that this would ultimately be very bad for the community at
> large. LLVM would become a graveyard


Graveyard sounds like abandoned backends - I think we're all agreed that if
a backend (public or private) ever became abandoned, it would be swiftly
removed.


> of odd back-ends that don't
> relate to each other,


I'm not sure I follow this - what do you mean by "don't relate to each
other" - most of our backends don't relate to each other, do they?


> that can't be proven right or wrong, that can't
> be tested or probed and we'd be at the mercy of all companies
> supporting them to "fix them as soon as they're able".
>

Why is that a mercy, though? At any point it's as working as the group that
cares about it working is willing to make it. The rest of the community
need not care (unless it's abandoned - at which point it should be removed)


> A community that relies on the benevolence of companies is *not* a
> healthy community. Not to name names, but I'm sure you can think of a
> few related to OO languages and databases.
>
> So, my view of official back-ends is that:
>  * It's available to the general public and is of interest to more
> than the company maintaining it
>  * It has a clear way to pass/fail and add regression tests to make
> sure we don't break again
>  * It allows the wider community to work on it, ie. not a selfish
> cost-cutting decision
>  * It has *some* representation outside the company who supports it
>
> Experimental back-ends, as Chris said, have a much lower threshold.
> I'm surprised we still keeping the CppBackend for this long.
>
> cheers,
> --renato
> _______________________________________________
> 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/20160210/baa28577/attachment.html>