[PATCH] RISC-V: Branches of vector extension are not merged into binutils mainline

[Jim Wilson]

On Thu, Jul 30, 2020 at 7:19 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> The other big issue with supporting anything that hasn't been ratified by the
> RISC-V foundation is: where do we draw the line as to what we accept?

Maybe when it hits 1.0?  I don't have a history of watching something
go through the approval process, so I don't know what kind of changes
or how many changes might be made between 1.0 (submitted for
ratification?) and 2.0 (ratified?).

> I'm way more worried about the embedded stuff, though.  As far as I can tell,
> most RISC-V development right now isn't for Linux-based systems and they all
> have some degree of non-standard extensions.  All the actual code I can find
> has trivial non-standard stuff (numbered CSRs and .insn stuff), but the
> marketing material alludes to much more complicated extensions and associated
> custom toolchains for support.  I assume that at least some of that is real,
> but maybe I just haven't properly learned my lesson about listening to the
> marketing people ;)

Yes, there are a lot of vendor extensions.  SiFive the only one that
has been contributing stuff upstream for the GNU toolchain, e.g. gcc
-mtune only has support for SiFive parts, but I'm starting to see
patches from Alibaba and Huawei.  SiFive hasn't tried to submit its
cache control instructions upstream yet though.  You can find a list
of Alibaba/T-Head XuanTie instruction extensions here
    https://github.com/isrc-cas/c910-llvm
just ask google translate to translate it if you can't read chinese.
Apparently word order is significant, and some of the confusingly
similar instructions are pre-increment versus post-increment.  Info on
Andes extensions can be found if you can read chinese and have access
to chinese search engines.  Our Taiwan office found some info.  The
most interesting one is a kind of table indirect instruction.
Apparently they have a linker patch to find the most common 4-byte
instructions, put them in a table, and then replace each use with a
2-byte table indirect instruction using the table index.  A cute idea,
but I'm not sure how practical that is.

> That's a good point -- I'd forgotten how much of a headache it is to maintain
> even simple stuff out of tree.  I suppose my assumption had been that these
> branches were going to be fairly short lived, but I suppose I was a bit too
> optimistic about the speed at which these ISA extensions would get finished.  I
> wouldn't be opposed to carrying the various draft extensions in tree, as long
> as everyone is OK with support for these being deprecated on arbitrary
> timelines (ie, new drafts get released).

I don't follow llvm.  They have added some support for unratified
extensions, but I don't know how they are dealing with this.  I do
know that qemu added support for rvv 0.7, and is now replacing it with
rvv 0.9+ support, which has no compatibility with the removed rvv 0.7
code.

> I'd even go so far as to say we should force a trivial source code change to
> build in support for the experimental stuff -- ie, put "#define
> SUPPORT_EXPERIMENTAL_EXTENSIONS 0" in riscv.h so "-mexperimental" won't even be
> accepted by standard builds.  That way users can't just get support for
> experimental extensions, they'd have to modify the source code so we'd have an
> easy way to make sure these don't drift into software.  I'm not sure if that's
> overkill, though.

That is an interesting idea but I'm also not certain if that is
necessary.  I think a -mexperimental would be enough, maybe with a
diagnostic printed to stdout to remind people they are using
experimental support that may have compatibility breaks.

Jim