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

# Overview and background

RISC-V is a free and open instruction set architecture. It is a modular
specification, with a range of standard extensions (e.g. floating point,
atomics, etc). New standard extensions are developed through RISC-V
Foundation working groups. The specifications for such extensions (e.g. vector
and bit manipulation) are publicly available, but are still in flux and
won't
be finalised until "ratified" by the Foundation. This RFC considers
how we
should handle review and merging of support for in-development standard
extensions, with a view to maximising collaboration and reduce duplicate effort.

The summarised proposal is that patches for in-development standard
extensions should be encouraged, but support should be gated by a sufficiently
unappetising flag and it should be made clear that it may change substantially
between LLVM releases, up until the standard is ratified.

# Discussion

RISC-V LLVM contributors have started posting patches to Phabricator that
start to implement both the proposed bit manipulation and vector extensions.
Leaving these patches uncommitted until the relevant extension is ratified
matches GCC's current approach, but significantly hampers the ability for
contributors to collaborate on these efforts using normal LLVM development
processes and infrastructure. I believe one motivation for the current GCC
policy is to avoid promoting fragmentation within the RISC-V ecosystem. I'm
hugely concerned that two RISC-V vendors have announced IP offerings
supporting the not yet finalised vector extension, yet don't feel it's
the
LLVM community's role to try to police this.

I believe code should be committed to LLVM when it is of sufficient
quality, when it can be shown to benefit the LLVM user or developer
communities, and when there is someone willing to support it. All of these can
be true even for unratified standard RISC-V extensions, with a caveat on
"support". It may not be appropriate to try to police RISC-V
fragmentation,
but we also shouldn't needlessly add to it. Shipping compiler support may
further encourage hardware with unfinalised specifications, and so we should
guard it behind suitably discouraging flags and be clear that the
implementation will change to match the specification up until it's
finalised.
Naturally we want as many of the benefits of supporting these extensions
upstream with as few downsides as possible. Limiting development to downstream
branches can be a barrier to collaboration, and pushes people away from the
upstream LLVM community.

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.

Option 2) has some precedent in the form of flags like
`-fexperimental-new-pass-manager`. Option 3) doesn't have precedent in LLVM,
but Robin Kruppe pointed out it has similarities to Rust, where experimental
features can only be enabled in nightly builds.

# Proposal

Although we want to discourage downstream reliance on unratified extensions,
there doesn't seem to be a strong motivation for requiring a custom LLVM
build
to force this. However, such unratified extensions shouldn't be accessible
via
normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and instead
flags of the
form `-riscv-experimental-vector-ext` in LLVM and `-mexperimental-vector-ext`
in Clang should be used (i.e. option 3)). We discussed this in our weekly call
however, and there were voices advocating either option 2 or 3. Input welcome.

If going down the option 3 route, the flags could be made more discouraging
through requiring an additional `-riscv-enable-experimental-extension` flag or
making the flag itself longer and scarier. Thoughts?

If there is agreement that this is a sensible approach, we'd work to review
and refine the proposed patches starting bit manipulation and vector extension
support with a goal of getting them committed once of a sufficient quality.

# Credits
Thanks for input from Sam Elliott and Luís Marques on the lowRISC
toolchain team, and for participants of the RISC-V sync-up call for
initial feedback (especially Robin Kruppe and Evandro Menezes).

Best,

Alex Bradbury,
CTO and Co-founder, lowRISC CIC

On Thu, 16 Jan 2020 at 18:01, Alex Bradbury <asb at lowrisc.org>
wrote:
>
> # Overview and background
>
> RISC-V is a free and open instruction set architecture. It is a modular
> specification, with a range of standard extensions (e.g. floating point,
> atomics, etc). New standard extensions are developed through RISC-V
> Foundation working groups. The specifications for such extensions (e.g.
vector
> and bit manipulation) are publicly available, but are still in flux and
won't
> be finalised until "ratified" by the Foundation. This RFC
considers how we
> should handle review and merging of support for in-development standard
> extensions, with a view to maximising collaboration and reduce duplicate
effort.
>
> The summarised proposal is that patches for in-development standard
> extensions should be encouraged, but support should be gated by a
sufficiently
> unappetising flag and it should be made clear that it may change
substantially
> between LLVM releases, up until the standard is ratified.
>
> # Discussion
>
> RISC-V LLVM contributors have started posting patches to Phabricator that
> start to implement both the proposed bit manipulation and vector
extensions.
> Leaving these patches uncommitted until the relevant extension is ratified
> matches GCC's current approach, but significantly hampers the ability
for
> contributors to collaborate on these efforts using normal LLVM development
> processes and infrastructure. I believe one motivation for the current GCC
> policy is to avoid promoting fragmentation within the RISC-V ecosystem.
I'm
> hugely concerned that two RISC-V vendors have announced IP offerings
> supporting the not yet finalised vector extension, yet don't feel
it's the
> LLVM community's role to try to police this.
>
> I believe code should be committed to LLVM when it is of sufficient
> quality, when it can be shown to benefit the LLVM user or developer
> communities, and when there is someone willing to support it. All of these
can
> be true even for unratified standard RISC-V extensions, with a caveat on
> "support". It may not be appropriate to try to police RISC-V
fragmentation,
> but we also shouldn't needlessly add to it. Shipping compiler support
may
> further encourage hardware with unfinalised specifications, and so we
should
> guard it behind suitably discouraging flags and be clear that the
> implementation will change to match the specification up until it's
finalised.
> Naturally we want as many of the benefits of supporting these extensions
> upstream with as few downsides as possible. Limiting development to
downstream
> branches can be a barrier to collaboration, and pushes people away from the
> upstream LLVM community.
>
> 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.
>
> Option 2) has some precedent in the form of flags like
> `-fexperimental-new-pass-manager`. Option 3) doesn't have precedent in
LLVM,
> but Robin Kruppe pointed out it has similarities to Rust, where
experimental
> features can only be enabled in nightly builds.
This should read:
Option 3) has some precedent in the form of flags like
`-fexperimental-new-pass-manager`. Option 2) doesn't have precedent in LLVM,
but Robin Kruppe pointed out it has similarities to Rust, where experimental
features can only be enabled in nightly builds.
> # Proposal
>
> Although we want to discourage downstream reliance on unratified
extensions,
> there doesn't seem to be a strong motivation for requiring a custom
LLVM build
> to force this. However, such unratified extensions shouldn't be
accessible via
> normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and instead
flags of the
> form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
> in Clang should be used (i.e. option 3)). We discussed this in our weekly
call
> however, and there were voices advocating either option 2 or 3. Input
welcome.
>
> If going down the option 3 route, the flags could be made more discouraging
> through requiring an additional `-riscv-enable-experimental-extension` flag
or
> making the flag itself longer and scarier. Thoughts?
>
> If there is agreement that this is a sensible approach, we'd work to
review
> and refine the proposed patches starting bit manipulation and vector
extension
> support with a goal of getting them committed once of a sufficient quality.
>
> # Credits
> Thanks for input from Sam Elliott and Luís Marques on the lowRISC
> toolchain team, and for participants of the RISC-V sync-up call for
> initial feedback (especially Robin Kruppe and Evandro Menezes).
>
> Best,
>
> Alex Bradbury,
> CTO and Co-founder, lowRISC CIC

On 01/16/2020 10:02 AM, Alex Bradbury via llvm-dev
wrote:
> On Thu, 16 Jan 2020 at 18:01, Alex Bradbury <asb at lowrisc.org>
wrote:
>>
>> # Overview and background
>>
>> RISC-V is a free and open instruction set architecture. It is a modular
>> specification, with a range of standard extensions (e.g. floating
point,
>> atomics, etc). New standard extensions are developed through RISC-V
>> Foundation working groups. The specifications for such extensions (e.g.
vector
>> and bit manipulation) are publicly available, but are still in flux and
won't
>> be finalised until "ratified" by the Foundation. This RFC
considers how we
>> should handle review and merging of support for in-development standard
>> extensions, with a view to maximising collaboration and reduce
duplicate effort.
>>
>> The summarised proposal is that patches for in-development standard
>> extensions should be encouraged, but support should be gated by a
sufficiently
>> unappetising flag and it should be made clear that it may change
substantially
>> between LLVM releases, up until the standard is ratified.
>>
>> # Discussion
>>
>> RISC-V LLVM contributors have started posting patches to Phabricator
that
>> start to implement both the proposed bit manipulation and vector
extensions.
>> Leaving these patches uncommitted until the relevant extension is
ratified
>> matches GCC's current approach, but significantly hampers the
ability for
>> contributors to collaborate on these efforts using normal LLVM
development
>> processes and infrastructure. I believe one motivation for the current
GCC
>> policy is to avoid promoting fragmentation within the RISC-V ecosystem.
I'm
>> hugely concerned that two RISC-V vendors have announced IP offerings
>> supporting the not yet finalised vector extension, yet don't feel
it's the
>> LLVM community's role to try to police this.
>>
>> I believe code should be committed to LLVM when it is of sufficient
>> quality, when it can be shown to benefit the LLVM user or developer
>> communities, and when there is someone willing to support it. All of
these can
>> be true even for unratified standard RISC-V extensions, with a caveat
on
>> "support". It may not be appropriate to try to police RISC-V
fragmentation,
>> but we also shouldn't needlessly add to it. Shipping compiler
support may
>> further encourage hardware with unfinalised specifications, and so we
should
>> guard it behind suitably discouraging flags and be clear that the
>> implementation will change to match the specification up until it's
finalised.
>> Naturally we want as many of the benefits of supporting these
extensions
>> upstream with as few downsides as possible. Limiting development to
downstream
>> branches can be a barrier to collaboration, and pushes people away from
the
>> upstream LLVM community.
>>
>> 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 personally prefer option 3.  Additional build flags are a burden on the
rest of the community and confusing for users in my opinion.

-Tom
>> Option 2) has some precedent in the form of flags like
>> `-fexperimental-new-pass-manager`. Option 3) doesn't have precedent
in LLVM,
>> but Robin Kruppe pointed out it has similarities to Rust, where
experimental
>> features can only be enabled in nightly builds.
> 
> This should read:
> Option 3) has some precedent in the form of flags like
> `-fexperimental-new-pass-manager`. Option 2) doesn't have precedent in
LLVM,
> but Robin Kruppe pointed out it has similarities to Rust, where
experimental
> features can only be enabled in nightly builds.
> 
>> # Proposal
>>
>> Although we want to discourage downstream reliance on unratified
extensions,
>> there doesn't seem to be a strong motivation for requiring a custom
LLVM build
>> to force this. However, such unratified extensions shouldn't be
accessible via
>> normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and
instead flags of the
>> form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
>> in Clang should be used (i.e. option 3)). We discussed this in our
weekly call
>> however, and there were voices advocating either option 2 or 3. Input
welcome.
>>
>> If going down the option 3 route, the flags could be made more
discouraging
>> through requiring an additional `-riscv-enable-experimental-extension`
flag or
>> making the flag itself longer and scarier. Thoughts?
>>
>> If there is agreement that this is a sensible approach, we'd work
to review
>> and refine the proposed patches starting bit manipulation and vector
extension
>> support with a goal of getting them committed once of a sufficient
quality.
>>
>> # Credits
>> Thanks for input from Sam Elliott and Luís Marques on the lowRISC
>> toolchain team, and for participants of the RISC-V sync-up call for
>> initial feedback (especially Robin Kruppe and Evandro Menezes).
>>
>> Best,
>>
>> Alex Bradbury,
>> CTO and Co-founder, lowRISC CIC
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

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
> 
> Option 2) has some precedent in the form of flags like
> `-fexperimental-new-pass-manager`. Option 3) doesn't have precedent in
LLVM,
> but Robin Kruppe pointed out it has similarities to Rust, where
experimental
> features can only be enabled in nightly builds.
> 
> # Proposal
> 
> Although we want to discourage downstream reliance on unratified
extensions,
> there doesn't seem to be a strong motivation for requiring a custom
LLVM build
> to force this. However, such unratified extensions shouldn't be
accessible via
> normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and instead
flags of the
> form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
> in Clang should be used (i.e. option 3)). We discussed this in our weekly
call
> however, and there were voices advocating either option 2 or 3. Input
welcome.
> 
> If going down the option 3 route, the flags could be made more discouraging
> through requiring an additional `-riscv-enable-experimental-extension` flag
or
> making the flag itself longer and scarier. Thoughts?
> 
> If there is agreement that this is a sensible approach, we'd work to
review
> and refine the proposed patches starting bit manipulation and vector
extension
> support with a goal of getting them committed once of a sufficient quality.
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.

This would avoid the ambiguity of the "which experimental b extension
does the compiler support" problem all the way until an extension is
ratified by making it explicit everywhere. My concern with a blanket
"enable the experimental support for X" approach is if users depend on
them (because they will, regardless of the name of the flag), then when
the supported version by the compiler changes, we should stop a user
from generating code that for their use case would then be invalid.

Alongside this I would add relevant error messages noting the current
version supported e.g. "this clang only supports b extension version
0.91". I appreciate we don't want to support every unratified version
of
an extension, but I think maintaining a check that the user wants "the
current supported version" is probably a good balance.


Thanks,
Simon

On Thu, 16 Jan 2020 at 19:27, Simon Cook via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 16/01/2020 18:01, Alex Bradbury via llvm-dev wrote:
> > # Proposal
> >
> > Although we want to discourage downstream reliance on unratified
extensions,
> > there doesn't seem to be a strong motivation for requiring a
custom LLVM build
> > to force this. However, such unratified extensions shouldn't be
accessible via
> > normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and
instead flags of the
> > form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
> > in Clang should be used (i.e. option 3)). We discussed this in our
weekly call
> > however, and there were voices advocating either option 2 or 3. Input
welcome.
> >
> > If going down the option 3 route, the flags could be made more
discouraging
> > through requiring an additional `-riscv-enable-experimental-extension`
flag or
> > making the flag itself longer and scarier. Thoughts?
> >
> > If there is agreement that this is a sensible approach, we'd work
to review
> > and refine the proposed patches starting bit manipulation and vector
extension
> > support with a goal of getting them committed once of a sufficient
quality.
>
> 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.
Thanks for the feedback Simon. I'd considered sticking to just the ISA
string, but my concern was that (and I'll admit this is just a gut
feeling) that it might imply a level of support / stability that
simply isn't there. In particular, people might get the impression
that b0p92 will continue to be supported, when we'd want to avoid
supporting old unratified spec versions (or even reasoning about
whether they remain supported or not due to later spec changes). But I
accept that the separate flag means that we break the property that
you can describe the targeted architecture concisely with a single
string.

Best,

Alex

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>

On Jan 16, 2020, at 10:01 AM, Alex Bradbury via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> # Overview and background
> 
> RISC-V LLVM contributors have started posting patches to Phabricator that
> start to implement both the proposed bit manipulation and vector
extensions.
> Leaving these patches uncommitted until the relevant extension is ratified
> matches GCC's current approach, but significantly hampers the ability
for
> contributors to collaborate on these efforts using normal LLVM development
> processes and infrastructure. I believe one motivation for the current GCC
> policy is to avoid promoting fragmentation within the RISC-V ecosystem.
I'm
> hugely concerned that two RISC-V vendors have announced IP offerings
> supporting the not yet finalised vector extension, yet don't feel
it's the
> LLVM community's role to try to police this.
Thank you for raising this concern and getting ahead of it.  I agree with you
completely that we should aspire to have people work together, and duplicating
effort with similar but different patches doesn’t help things.
> I believe code should be committed to LLVM when it is of sufficient
> quality, when it can be shown to benefit the LLVM user or developer
> communities, and when there is someone willing to support it. All of these
can
> be true even for unratified standard RISC-V extensions, with a caveat on
> "support”.
+1
> # Proposal
> 
> Although we want to discourage downstream reliance on unratified
extensions,
> there doesn't seem to be a strong motivation for requiring a custom
LLVM build
> to force this. However, such unratified extensions shouldn't be
accessible via
> normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and instead
flags of the
> form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
> in Clang should be used (i.e. option 3)). We discussed this in our weekly
call
> however, and there were voices advocating either option 2 or 3. Input
welcome.
> 
> If going down the option 3 route, the flags could be made more discouraging
> through requiring an additional `-riscv-enable-experimental-extension` flag
or
> making the flag itself longer and scarier. Thoughts?
I think you’ve got the right tradeoff here.  If I’m understanding your plan, it
is:

 - don’t add extensions to the isa naming string until they are finalized.

 - in-progress extensions can land in mainline LLVM, and are protected under a
-experimental-foo style of flag.  There is no support implied
or compatibility in the future for such flags, they can be changed or removed at
any time, they are just for staging.

 - it doesn’t seem like there is any need to #ifdef out these flags.  A scary
enough flag name should be fine.  The goal isn’t to prevent malice, it is to
prevent accidental reliance.

This all makes sense to me.
> If there is agreement that this is a sensible approach, we'd work to
review
> and refine the proposed patches starting bit manipulation and vector
extension
> support with a goal of getting them committed once of a sufficient quality.
Fantastic, thank you for the very nice summary and for driving this discussion
Alex!

-Chris

On Tue, 21 Jan 2020 at 01:14, Chris Lattner <clattner at nondot.org>
wrote:
>
> On Jan 16, 2020, at 10:01 AM, Alex Bradbury via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> > I believe code should be committed to LLVM when it is of sufficient
> > quality, when it can be shown to benefit the LLVM user or developer
> > communities, and when there is someone willing to support it. All of
these can
> > be true even for unratified standard RISC-V extensions, with a caveat
on
> > "support”.
>
> +1
>
> > # Proposal
> >
> > Although we want to discourage downstream reliance on unratified
extensions,
> > there doesn't seem to be a strong motivation for requiring a
custom LLVM build
> > to force this. However, such unratified extensions shouldn't be
accessible via
> > normal RISC-V ISA naming strings (e.g. "rv32imafdc"), and
instead flags of the
> > form `-riscv-experimental-vector-ext` in LLVM and
`-mexperimental-vector-ext`
> > in Clang should be used (i.e. option 3)). We discussed this in our
weekly call
> > however, and there were voices advocating either option 2 or 3. Input
welcome.
> >
> > If going down the option 3 route, the flags could be made more
discouraging
> > through requiring an additional `-riscv-enable-experimental-extension`
flag or
> > making the flag itself longer and scarier. Thoughts?
>
> I think you’ve got the right tradeoff here.  If I’m understanding your
plan, it is:
>
>  - don’t add extensions to the isa naming string until they are finalized.
>
>  - in-progress extensions can land in mainline LLVM, and are protected
under a -experimental-foo style of flag.  There is no support implied
> or compatibility in the future for such flags, they can be changed or
removed at any time, they are just for staging.
>
>  - it doesn’t seem like there is any need to #ifdef out these flags.  A
scary enough flag name should be fine.  The goal isn’t to prevent malice, it is
to prevent accidental reliance.
>
> 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.

So based on feedback so far, I'd like to narrow the field to:

Option 1)
* Unratified extensions are not available through the ISA naming
string and are enabled via `-riscv-experimental-foo` or similar
* A warning is always emitted when enabling experimental extensions
* Support is always compiled in, and the flags aren't ifdeffed out

Option 2)
* Unratified extensions can be enabled by passing a flag like
-riscv-enable-experimental-extensions and additionally putting the
extension name and version number in the ISA naming string (version
number is always required, and we will only accept the 'current'
version number).
* A warning is always emitted when enabling experimental extensions
* Support is always compiled in, and the flags aren't ifdeffed out

Best,

Alex