[llvm-dev] [RFC] Lanai backend

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 10 03:40:24 PST 2016

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

There is a big difference, in my view, between a "technology preview"
and a "cost-cutting decision". 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 of odd back-ends that don't
relate to each other, 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".

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.


More information about the llvm-dev mailing list