[llvm-dev] Target Acceptance Policy

[Mehdi Amini via llvm-dev]

> On Jul 25, 2016, at 4:18 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Folks,
> 
> In recent discussions about accepting the Lanai back-end as official
> (built by default), there was the idea that we should have some
> official guidelines, if not rules, that all targets must (should?)
> follow when requesting to be added upstream, and later, to be
> officially supported.
> 
> Here's a list of what more or less converged into the thread with my
> personal bias.
> 
> Must haves to be accepted upstream as experimental:
> 
> 1. There must be an active community behind the target. This community will be
>  the maintainers of the target by providing buildbots, fixing bugs, answering
>  the LLVM community's questions and making sure the new target doesn't break
>  any of the other targets, or generic code.
> 
> 2. The code must be free of contentious issues, for example, large
> changes in how
>  the IR behaves or should be formed by the front-ends, unless agreed by the
>  majority of the community via refactoring of the (LangRef) *before*
> the merge of
>  the new target changes, following the IR backwards compatibility described in
>  the developer's policy document.
> 
> 3. The code has a compatible license, patent and copyright statements, or can be
>  converted by the LLVM's own model.
> 
> Where applicable:
> 
> 4. The target should have either reasonable documentation on how it works (ISA,
>  ABI, etc.) or a publicly available simulator/hardware (either free
> or cheap enough),
>  so that developers can validate assumptions, understand constraints and review
>  code that can affect the target. Preferably both.
> 
> To be moved as an official target:
> 
> 5. The target must have been in the tree for at least 6 months, with active
>  contributions including: adding more tests conforming to the documents, fixing
>  bugs reported by unrelated/generic changes, providing support to other members
>  of the community.
> 
> 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.

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

— 
Mehdi



> 
> My takes on those:
> 
> I don't think we should avoid 1, 2 and 3 for any reasons, or we'll be
> shooting ourselves in th foot.
> 
> 4 is only applicable to actual executing targets, and may clash with
> existing targets like GPUs, BPF, etc. While I'd *really* like to have
> some execution model for GPUs, I'm not prepared to recommend
> jettisoning their back-ends without it. :)
> 
> 5 states "6 months" as a ball-park. I'm not too fixed on that, and I
> welcome ideas if anyone feels strongly about time taken. I think it
> needs to give us enough time to assess the *other* points (es.
> community, tests, validation, response).
> 
> 6 I think it's a strong factor and I feel very strongly about it. We
> had projects before merging with other code styles and policies, but
> as an "LLVM developer", I feel I should be able to contribute to any
> "officially branded LLVM project". So, if those targets want to be
> part of *our* community, they have to abide by the same rules.
> 
> 7 is hard to know, and I'm not sure how much we can really enforce.
> Maybe demanding at least one public buildbot? What if the target can't
> execute or even run clang? Wouldn't the target's tests on other bots
> be enough?
> 
> Opinions?
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev