[llvm-dev] Target Acceptance Policy
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 16:18:05 PDT 2016
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
Here's a list of what more or less converged into the thread with my
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.
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
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
More information about the llvm-dev