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

[Alex Bradbury via llvm-dev]

# 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.

# 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