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

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 26 11:07:52 PST 2020

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


More information about the llvm-dev mailing list