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

[Chris Lattner via llvm-dev]

On Jan 16, 2020, at 10:01 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> # Overview and background
> 
> 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.

Thank you for raising this concern and getting ahead of it.  I agree with you completely that we should aspire to have people work together, and duplicating effort with similar but different patches doesn’t help things.

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

+1

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

I think you’ve got the right tradeoff here.  If I’m understanding your plan, it is:

 - don’t add extensions to the isa naming string until they are finalized.

 - in-progress extensions can land in mainline LLVM, and are protected under a -experimental-foo style of flag.  There is no support implied 
or compatibility in the future for such flags, they can be changed or removed at any time, they are just for staging.

 - it doesn’t seem like there is any need to #ifdef out these flags.  A scary enough flag name should be fine.  The goal isn’t to prevent malice, it is to prevent accidental reliance.

This all makes sense to me.

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

Fantastic, thank you for the very nice summary and for driving this discussion Alex!

-Chris