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

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 17 07:32:44 PST 2020


On Thu, Jan 16, 2020 at 2:28 PM Simon Cook via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On 16/01/2020 18:01, Alex Bradbury via llvm-dev wrote:
> >
> > I believe this situation is somewhat new to LLVM, as typically work on
> new ISA
> > extensions/revisions is performed behind closed doors until the final
> version
> > is announced.
> >
> > There are multiple options for inclusion of an unratified standard
> extension
> > upstream:
> > 1) Feature is in-tree, but only compiled with an explicit flag. Guarding
> by
> >   ifdefs is likely to get ugly, and this also requires extra build bots
> >   etc.
> > 2) Feature always compiled, but the code path to enable it is disabled
> >   without a particular build flag. Also needs extra build bots.
> > 3) Feature is always compiled and can be enabled regardless of LLVM
> >   build flags used.
>
> I would steer away from needing extra build time flags to enable these
> extensions. If most people don't use these flags then there's a risk of
> these bitrotting or getting broken by other patches in the backend or
> elsewhere and may add to the support burg
>

I'd agree that compile-time optionality is best avoided when possible.

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


That march flag doesn't scream out to me "Warning! You're using an
experimental extension which will probably be changed incompatibly in the
next release!" like an explicit command-line flag could do.

One way to resolve this would be to require _both_ -- you must specify your
ISA options with explicit versions in the ISA string, but, doing so would
print an error without a separate flag also being enabled, e.g. "error: ISA
extension b0p92 is an experimental extension, and support may be removed in
future LLVM releases. Pass -mallow-experimental-riscv-isa-extensions to
enable."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/e011f992/attachment-0001.html>


More information about the llvm-dev mailing list