Krzysztof Parzyszek via llvm-dev
2016-Jul-19 14:17 UTC
[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
Martin J. O'Riordan via llvm-dev
2016-Jul-19 16:04 UTC
[llvm-dev] [RFC] Make Lanai backend non-experimental
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 lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Renato Golin via llvm-dev
2016-Jul-19 16:42 UTC
[llvm-dev] [RFC] Make Lanai backend non-experimental
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