[doc] Clarify responsibility for fixing experimental target problems

[jhenderson]

Summary

Experimental targets are meant to be maintained by the community behind the target. They are not monitored by the primary build bots. This change clarifies that it is this communities responsibility for things like test fixes related to the target caused by changes unrelated to that target.

See http://lists.llvm.org/pipermail/llvm-dev/2020-February/139115.html for a full discussion.

[jhenderson]

Upload correct diff with better wording.

[thakis]

Fine with me, but I think the more interesting conversation to have is one about the future of the AVR target. The AVR target is the only experimental target that currently exists.

It's been in the tree for a while now, so it should either become stable or move out of tree again.

The last commit by the code owner is from July 2019. I don't have any relation with the AVR target except that I have a bot that builds with all targets enabled. Nobody seems to be fixing AVR issues, and git log llvm/lib/Target/AVR only shows global refactoring changes modifying that directory.

So this kind of suggests "remove the AVR target".

On the other hand, e.g. XCore is in even worse shape (code owner inactive since Aug 2014) and that's a non-experimental target. And it's not like AVR needs all that much maintenance. So we could make it non-experimental as well.

I don't have an opinion on either. But it seems like experimental targets shouldn't stay experimental for many years.

[thakis]

I suppose that's similar to what Matt said in http://lists.llvm.org/pipermail/llvm-dev/2020-February/139117.html :)

[thakis]

https://reviews.llvm.org/p/dylanmckay/ looks pretty active. So I think promoting AVR to non-experimental might make sense.

[rupprecht]

Thanks James!

In D74538#1874417, @thakis wrote:

Fine with me, but I think the more interesting conversation to have is one about the future of the AVR target. The AVR target is the only experimental target that currently exists.

It's been in the tree for a while now, so it should either become stable or move out of tree again.

The last commit by the code owner is from July 2019. I don't have any relation with the AVR target except that I have a bot that builds with all targets enabled. Nobody seems to be fixing AVR issues, and git log llvm/lib/Target/AVR only shows global refactoring changes modifying that directory.

So this kind of suggests "remove the AVR target".

On the other hand, e.g. XCore is in even worse shape (code owner inactive since Aug 2014) and that's a non-experimental target. And it's not like AVR needs all that much maintenance. So we could make it non-experimental as well.

I don't have an opinion on either. But it seems like experimental targets shouldn't stay experimental for many years.

Yes, I don't have an opinion either way, but just to be clear, this is an orthogonal discussion that's unrelated to this patch. I'd recommend starting a thread on llvm-dev.

[MaskRay]

llvm/docs/DeveloperPolicy.rst

576

This cmake variable is LLVM_EXPERIMENTAL_TARGETS_TO_BUILD

For example, to enable all currently experimental targets:

-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD='ARC;AVR;VE'

[lattner]

Very nice, please correct the CMAKE variable or, better yet, just drop the explicit mention of the flag to pass). I really appreciate that you are improving our policies!

[jhenderson]

Removed reference to CMake variable.

[jhenderson]

Thanks for the comments! I've updated the text to remove reference to the explicit variable, and will go ahead and push this shortly.

Regarding the future of the AVR and other experimental targets, that definitely should be brought up on the mailing list in a separate discussion. This change should just be codifying what the already generally understood policy is.

llvm/docs/DeveloperPolicy.rst

 
 LLVM is very receptive to new targets, even experimental ones, but a number of
 problems can appear when adding new large portions of code, and back-ends are
 normally added in bulk.  We have found that landing large pieces of new code 
 and then trying to fix emergent problems in-tree is problematic for a variety 
 of reasons.
 
 For these reasons, new targets are *always* added as *experimental* until
-they can be proven stable, and later moved to non-experimental. The difference
-between both classes is that experimental targets are not built by default
-(need to be added to -DLLVM_TARGETS_TO_BUILD at CMake time).
+they can be proven stable, and later moved to non-experimental. The differences
+between both classes are:
+
+* Experimental targets are not built by default (they need to be explicitly
+  enabled at CMake time).
+
+* Test failures, bugs, and build breakages that only appear when the
+  experimental target is enabled, caused by changes unrelated to the target, are
+  the responsibility of the community behind the target to fix.
 
 The basic rules for a back-end to be upstreamed in **experimental** mode are:
 
 * Every target must have a :ref:`code owner<code owners>`. The `CODE_OWNERS.TXT`
   file has to be updated as part of the first merge. The code owner makes sure
   that changes to the target get reviewed and steers the overall effort.
 
 * There must be an active community behind the target. This community