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

[Bruce Hoult via llvm-dev]

On Sun, Jan 26, 2020 at 11:08 AM Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> > On Jan 23, 2020, at 6:58 AM, Alex Bradbury <asb at lowrisc.org> wrote:
> >
> > On Wed, 22 Jan 2020 at 19:55, Chris Lattner via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> On Jan 21, 2020, at 5:00 AM, Alex Bradbury <asb at lowrisc.org> wrote:
> >>>> This all makes sense to me.
> >>>
> >>> That's correct, thanks for the feedback.
> >>>
> >>> I do like the idea from James of having the compiler always spit out a
> >>> note when enabling the experimental extension, warning of its
> >>> experimental nature. If we had such a warning and additionally
> >>> required a `-riscv-enable-experimental-extensions` or similar, then I
> >>> think there could be merit in including in the ISA string as Simon
> >>> suggests, especially as we're likely to start putting that string in
> >>> ELF output etc.
> >>
> >> Are you suggesting this behavior from Clang or from LLVM?  I think it would be a bad thing for LLVM to produce this warning: there isn’t a precedent for this, and it breaks the library-based design goals.  Having clang produce a warning could be done, but it would be very noisy (one warning for every .c file in a build) and I’m not sure how much value it provides.
> >
> > That's a good point. It felt like there may be an opportunity to
> > educate users that they're enabling a feature that might mutate from
> > release to release, but hopefully the "experimental" string in the
> > flag name indicates that, and as you say there's not much precedent
> > for such noisy warnings. After all, you can have a really bad time by
> > setting -mstack-alignment and not understanding the consequences.
> >
> > So I'm in favour of dropping the noisy warning idea.
> >
> > Thanks again for the input, and thanks James for your clarification.
>
> +1, I think the “experimental” in the name of the flag is sufficiently scary.  Thanks!

Something no one has mentioned is the way the RISC-V ratification process works.

Alex touched on this when he mentioned that in other ISAs development
work is done behind closed doors, and only announced when finished.
But it's more than simply this.

In the RISC-V world, ISA extensions will *not* be ratified until
experience is gained with them on real hardware, in real world use.
This necessitates having toolchain support *before* ratification,
otherwise the experience necessary to gain ratification will never
happen.

This point also need to be made somehow to the gcc community.

I agree with the concept of the code always being compiled to avoid
bitrot (as much as possible), and simply guarded with a scary
"experimental" flag.

p.s. it's really great to see Chris take a greater interest in RISC-V
and I look forward to seeing him around the SiFive offices!