[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 19:27, Simon Cook via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 16/01/2020 18:01, Alex Bradbury via llvm-dev wrote:
> > # 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.

Thanks for the feedback Simon. I'd considered sticking to just the ISA
string, but my concern was that (and I'll admit this is just a gut
feeling) that it might imply a level of support / stability that
simply isn't there. In particular, people might get the impression
that b0p92 will continue to be supported, when we'd want to avoid
supporting old unratified spec versions (or even reasoning about
whether they remain supported or not due to later spec changes). But I
accept that the separate flag means that we break the property that
you can describe the targeted architecture concisely with a single
string.

Best,

Alex