[llvm-dev] [RFC] Upstream development of support for yet-to-be-ratified RISC-V extensions

[Alex Bradbury via llvm-dev]

On Thu, 16 Jan 2020 at 18:01, Alex Bradbury <asb at lowrisc.org> wrote:
>
> # Overview and background
>
> RISC-V is a free and open instruction set architecture. It is a modular
> specification, with a range of standard extensions (e.g. floating point,
> atomics, etc). New standard extensions are developed through RISC-V
> Foundation working groups. The specifications for such extensions (e.g. vector
> and bit manipulation) are publicly available, but are still in flux and won't
> be finalised until "ratified" by the Foundation. This RFC considers how we
> should handle review and merging of support for in-development standard
> extensions, with a view to maximising collaboration and reduce duplicate effort.
>
> The summarised proposal is that patches for in-development standard
> extensions should be encouraged, but support should be gated by a sufficiently
> unappetising flag and it should be made clear that it may change substantially
> between LLVM releases, up until the standard is ratified.
>
> # Discussion
>
> RISC-V LLVM contributors have started posting patches to Phabricator that
> start to implement both the proposed bit manipulation and vector extensions.
> Leaving these patches uncommitted until the relevant extension is ratified
> matches GCC's current approach, but significantly hampers the ability for
> contributors to collaborate on these efforts using normal LLVM development
> processes and infrastructure. I believe one motivation for the current GCC
> policy is to avoid promoting fragmentation within the RISC-V ecosystem. I'm
> hugely concerned that two RISC-V vendors have announced IP offerings
> supporting the not yet finalised vector extension, yet don't feel it's the
> LLVM community's role to try to police this.
>
> I believe code should be committed to LLVM when it is of sufficient
> quality, when it can be shown to benefit the LLVM user or developer
> communities, and when there is someone willing to support it. All of these can
> be true even for unratified standard RISC-V extensions, with a caveat on
> "support". It may not be appropriate to try to police RISC-V fragmentation,
> but we also shouldn't needlessly add to it. Shipping compiler support may
> further encourage hardware with unfinalised specifications, and so we should
> guard it behind suitably discouraging flags and be clear that the
> implementation will change to match the specification up until it's finalised.
> Naturally we want as many of the benefits of supporting these extensions
> upstream with as few downsides as possible. Limiting development to downstream
> branches can be a barrier to collaboration, and pushes people away from the
> upstream LLVM community.
>
> I believe this situation is somewhat new to LLVM, as typically work on new ISA
> extensions/revisions is performed behind closed doors until the final version
> is announced.
>
> There are multiple options for inclusion of an unratified standard extension
> upstream:
> 1) Feature is in-tree, but only compiled with an explicit flag. Guarding by
>   ifdefs is likely to get ugly, and this also requires extra build bots
>   etc.
> 2) Feature always compiled, but the code path to enable it is disabled
>   without a particular build flag. Also needs extra build bots.
> 3) Feature is always compiled and can be enabled regardless of LLVM
>   build flags used.
>
> Option 2) has some precedent in the form of flags like
> `-fexperimental-new-pass-manager`. Option 3) doesn't have precedent in LLVM,
> but Robin Kruppe pointed out it has similarities to Rust, where experimental
> features can only be enabled in nightly builds.

This should read:
Option 3) has some precedent in the form of flags like
`-fexperimental-new-pass-manager`. Option 2) doesn't have precedent in LLVM,
but Robin Kruppe pointed out it has similarities to Rust, where experimental
features can only be enabled in nightly builds.

> # Proposal
>
> Although we want to discourage downstream reliance on unratified extensions,
> there doesn't seem to be a strong motivation for requiring a custom LLVM build
> to force this. However, such unratified extensions shouldn't be accessible via
> normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and instead flags of the
> form `-riscv-experimental-vector-ext` in LLVM and `-mexperimental-vector-ext`
> in Clang should be used (i.e. option 3)). We discussed this in our weekly call
> however, and there were voices advocating either option 2 or 3. Input welcome.
>
> If going down the option 3 route, the flags could be made more discouraging
> through requiring an additional `-riscv-enable-experimental-extension` flag or
> making the flag itself longer and scarier. Thoughts?
>
> If there is agreement that this is a sensible approach, we'd work to review
> and refine the proposed patches starting bit manipulation and vector extension
> support with a goal of getting them committed once of a sufficient quality.
>
> # Credits
> Thanks for input from Sam Elliott and Luís Marques on the lowRISC
> toolchain team, and for participants of the RISC-V sync-up call for
> initial feedback (especially Robin Kruppe and Evandro Menezes).
>
> Best,
>
> Alex Bradbury,
> CTO and Co-founder, lowRISC CIC