[llvm-dev] Target Acceptance Policy

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 25 18:59:14 PDT 2016

On Mon, Jul 25, 2016 at 6:22 PM Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Jul 25, 2016, at 5:54 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> 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.
> There is a nuance: the fact that it is not developed in tree does not
> prevent from splitting it in “some” pieces that can be independently
> reviewed, this is what we (should) do for any large chunk of code that we
> integrate.
> Now it is possible that considering the current way of implementing
> backend in LLVM, there is not much pieces that can be split out of a
> backend (I still think that’s unfortunate though).

Sure, we should definitely split it in ways that make sense.

I was just pointing out that this won't be the same thing as what
"incremental development" would have naturally led to if the backend had
been in tree on day-one, and while we actually insist on nearly replaying
incremental development for some things, it doesn't seem likely to make
sense for a backend.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/8cc825f0/attachment.html>

More information about the llvm-dev mailing list