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

[Simon Cook via llvm-dev]

Hi all,

Following this discussion (and last week's RISC-V call) I've implemented
a first version of this in https://reviews.llvm.org/D73891. We've
rebased the other bitmanip patches (D65649, D67348 and D71553) to match,
and with these you should be able to use the 0.92 version of the B
extension using this method. Any feedback on the approach taken welcome.

Thanks,
Simon

On 28/01/2020 01:24, Bruce Hoult via llvm-dev wrote:
> 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!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>