Re: [PATCH 0/3] RISC-V: Add -menable-experimental-extensions and support bitmanip instructions

[Jim Wilson <jimw@sifive.com>]

On Tue, Dec 15, 2020 at 10:23 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> IIUC the plan is to start supporting draft extensions in binutils/GCC.  I
> don't
> do a whole lot of binutils/GCC work any more so I'm not sure my opinion
> should
> carry any weight, but I just wanted to point out that I think this is a bad
> policy to adopt.
>

There are multiple practical problems here.

LLVM is already accepting draft extensions.  If we don't, then we risk
losing the user community.

There are development issues here.  We have at least 3 different git repos
where B extension work is happening.  It is a mess.  The only place where I
can get everyone to agree to do work is the FSF repo.  The FSF repo is also
the only place where everyone that should have write access does have write
access.

The github riscv repos are causing problems.  The longer we use them, the
more problems that they cause.  I need to deprecate them.  But I can't
deprecate them until I get everything upstream, and that includes the draft
extension work that we have been doing there.

>
> The issue I have here is bringing code into binutils/GCC that we're
> intending
> on quickly deprecating -- for example, it appears this one implements a
> specification that hasn't even been versioned yet.  That is just not a way
> to
> build out a useable ecosystem.  Imagine the spot we'll be in a year or two
> from
> now trying to cobble together trees of the various systems projects that
> all
> speak the same flavor of an extension (doubly so if we can't rely on
> version
> numbers).
>

The code we are adding is expected to be unchanged in the official version
of the zbb and zba extensions.  This is of course no guarantee, but we have
multiple parties that have agreed on this.  So this is not code that we are
expecting to deprecate.  The other ones are still in flux and may need to
be deprecated.  The only real problem is that the current updated draft
hasn't been given a version number yet.  I've asked for one to be assigned
to it so that the patches can use that version number.

My personal bar for merging support for an extension would be the existence
> of
> hardware that implements that extension.
>

RVI has already decided that there must be toolchain support before we can
have an official hardware extension.  If we can't have official toolchain
support until the hardware extension is official that we have a circular
dependency and are screwed.  Something needs to go first here, and it makes
sense that it is the toolchain support.  So we add toolchain support first
conditional on -menable-experimental-extensions, and then the hardware
extension becomes official, and then the toolchain support is no longer
conditional on -menable-experimental-extensions.

>
> That said, that's all my personal bar.  If you want to support draft
> extensions
> earlier that's fine with me, it's your time and I'm fine with you spending
> it
> however you want.  I just don't want those extensions disappearing out from
> under me before we even know that they're going to remain unimplemented.  I
> know it's more work to support multiple versions of extensions, but we're
> going
> to have to do that at some point soon so we might as well just start taking
> that seriously now.
>

The whole point of the -menable-experimental-extensions option is that the
support may change in an incompatible way tomorrow.  If you don't like
that, then don't use the option.

Yes, we need to support multiple versions of extensions, and we are adding
support for that, but this is impractical to do for draft extensions, as
they can change in difficult to support ways, including backward
compatibillity breaks.  Once an extension becomes official, then there
should be no backward incompatible changes, and it gets easier to support
multiple versions.

Jim