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

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.

Best,

Alex

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

-Chris

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!