[llvm-dev] Target Acceptance Policy

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 25 17:54:30 PDT 2016

On Mon, Jul 25, 2016 at 5:47 PM Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > On Jul 25, 2016, at 4:18 PM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > 6. The target's code must have been adapted to the developers policy as
> well as
> >  the coding standards. This can take a while and it should be fine to
> > accept external code into LLVM as experimental, but not officially.
> FWIW I’m not fond of not having this as the experimental part in the first
> place.
> It is harder to have things moving after being upstreamed.
> I’d expect the upstreaming of a backend (into experimental state) to be
> piece by piece with proper code review according to the current project
> standard.

I'm not sure it makes sense to insist on backends being incrementally
developed in the open. While I rather prefer that (WebAssembly has been fun
to watch here), it doesn't seem realistic.

Every backend I can think of other than WebAssembly and the original
AArch64 port has come into existence out of tree, and only after proving
useful to some folks decided to move into the tree. I'd personally advocate
for keeping that door open.

All that said,I completely agree regarding coding conventions and other
basic stuff. I don't think we need to wait for the official point in time
to insist on all of the fundamental coding standards and such being

> >
> > A soft(-er?) requirement:
> >
> > 7. The test coverage is broad and well written (small tests,
> documented). Where
> >  applicable, both the ``check-all`` and  ``test-suite`` must pass in at
> least
> >  one configuration (publicly demonstrated, ex.  via buildbots).
> Same as before: this is a no-brainer should be applicable with any patch,
> even in experimental state: small and documented lit tests.

Yep, this seems like it should always be true regardless of the
experimental nature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/8bdcd4a1/attachment.html>

More information about the llvm-dev mailing list