llvm dev - Jul 2016 - [RFC] Make Lanai backend non-experimental

On 7/19/2016 6:12 AM, Renato Golin via llvm-dev wrote:
>
> I don't see why not. LGTM.
Same here.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Oops - meant to send this to the full list.

	MartinO

-----Original Message-----
From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] 
Sent: 19 July 2016 15:56
To: 'Krzysztof Parzyszek' <kparzysz at codeaurora.org>
Subject: RE: [llvm-dev] [RFC] Make Lanai backend non-experimental

I know this is a bit of a dumb question, but every so often I read about one
back-end or another being made "experimental", or promoted to
"non-experimental".

Presumably if my out-of-tree backend was to be pushed to LLVM, it too would be
considered experimental.  But what is involved in making a particular target,
feature or back-end experimental other than simply agreement?  Are there
particular build processes or '-Dmacroname's to add, or how does
somebody like me edit my out-of-tree sources so that it would obey the "is
experimental" rules?

Thanks,

	MartinO

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Krzysztof Parzyszek via llvm-dev
Sent: 19 July 2016 15:17
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Make Lanai backend non-experimental

On 7/19/2016 6:12 AM, Renato Golin via llvm-dev wrote:
>
> I don't see why not. LGTM.
Same here.

-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation _______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Presumably if my out-of-tree backend was to be pushed to LLVM, it too would
be considered experimental.
Yes. Though, not all out-of-tree back-ends end up upstream for
different reasons.

A few basic rules to get accepted are if:
 * the target exists and can be easily purchased / emulated for
investigating problems,
 * there are official documents / specs published by the project /
company that maintains the targets,
 * there is a reasonable community maintaining the rest of the system
(firmware, OS, other tools, etc),
 * enough people commit themselves to maintain the LLVM back-end to
avoid bit-rot,
 * the back-end is free of contentious features that would mean
breaking every other target.

For example:
 * a PIC back-end ticks many of the boxes, but it doesn't have a
community around it and would very quickly bit-rot,
 * the CHERI back-end has an active community and interested
developers, but it would disrupt the IR too much,
 * the BPF back-end has been added mostly as-is and is actively
maintained, so gained the status of non-experimental.

The main difference between experimental and official is that they get
built by default. So, if you don't specify them at CMake time, they
will be built and their tests will execute, which is a big win for the
back-end maintainers (as they get free testing), but it's also a big
burden on other developers if their tests are not independent enough
and keep breaking due to unrelated changes.

Under those conditions, it's as easy to remove a back-end that is too
much trouble and no one cares about, as it to add a new experimental
back-end or promote it to official. It all depends on the community
around it and how much they value the LLVM back-end.

>  But what is involved in making a particular target, feature or back-end
experimental other than simply agreement?  Are there particular build processes
or '-Dmacroname's to add, or how does somebody like me edit my
out-of-tree sources so that it would obey the "is experimental" rules?
I'm assuming you already have an implementation, for example, in
GitHub. The easiest way to get things started is to point people at
the repository and make sure it works on trunk.

The second step, then, would be to merge that into the tree and
propose to include it as an experimental target. It will take a few
months until the process is complete and then you'll be able to check
it out and work straight from LLVM's repository.

You'll have to change the CMake to force it to be built
(-DLLVM_TARGETS_TO_BUILD) until such time that you have shown that you
care about the target and that it hasn't failed (best if you have a
buildbot showing the history always green).

Once all that is done, you can do as Jacques did and request it to be
built by default (aka. non-experimental, aka. official back-end).

After that change, though, you're permanently enlisted to maintain it
even more intensely. Not just your buildbot will break, but other
people's too, and they're probably a lot faster than yours, so you
need to keep an eye on them, especially if they break due to unrelated
commits.

That is the contract that you have to sign to have your target
supported, and if you break that contract (let it bit-rot, disable
tests that should be passing, remove parts of the code, or just
neglects bug reports), your back-end *will* be removed.

Hope that helps,
--renato