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

[Tom Stellard via llvm-dev]

On 01/16/2020 10:02 AM, Alex Bradbury via llvm-dev wrote:
> 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.
>>

I personally prefer option 3.  Additional build flags are a burden on the
rest of the community and confusing for users in my opinion.

-Tom

>> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>