[llvm-dev] Target Acceptance Policy

[Renato Golin via llvm-dev]

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.

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

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