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

[Simon Cook via llvm-dev]

On 16/01/2020 18:01, Alex Bradbury via llvm-dev wrote:
> 
> 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 would steer away from needing extra build time flags to enable these
extensions. If most people don't use these flags then there's a risk of
these bitrotting or getting broken by other patches in the backend or
elsewhere and may add to the support burg

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

I would propose a different way of exposing this to the user, exposing
these extensions through the ISA string, but require that an explicit
version number is provided when requesting the extension using the
standard syntax. For example, bitmanip currently sits at version 0.92,
so I would have clang accept for example -march=rv32ib0p92, but error on
-march=rv32ib since it is not yet ratified.

This would avoid the ambiguity of the "which experimental b extension
does the compiler support" problem all the way until an extension is
ratified by making it explicit everywhere. My concern with a blanket
"enable the experimental support for X" approach is if users depend on
them (because they will, regardless of the name of the flag), then when
the supported version by the compiler changes, we should stop a user
from generating code that for their use case would then be invalid.

Alongside this I would add relevant error messages noting the current
version supported e.g. "this clang only supports b extension version
0.91". I appreciate we don't want to support every unratified version of
an extension, but I think maintaining a check that the user wants "the
current supported version" is probably a good balance.


Thanks,
Simon