Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension

[Jim Wilson <jim.wilson.gcc@gmail.com>]

On Wed, Apr 20, 2022 at 10:55 AM lkcl via Binutils <binutils@sourceware.org>
wrote:

> my understanding of custom extensions is that they are intended never,
> under any circumstances, to hit "upstream", due to the risk of creating
> massive conflict and confusion due to dominance of one extension over
> another, particularly if that custom extension achieves extremely
> commonly-used and high profile public status.
>

The RISC-V ISA has always planned for support for custom extensions.  We
have a part of the opcode space reserved for custom extensions, and we have
an arch string syntax for specifying custom extensions.   We are also
trying to standardize the naming conventions for custom extensions in
riscv-toolchain-conventions to avoid conflict.  See pull requests #17 and
#19.

Custom extensions are a fact of life.  All major RISC-V vendors have them.
You are suggesting that each vendor should maintain their own toolchain
source tree.  But if they all do that, then there is a risk that none will
contribute patches upstream.  We are better off if we allow vendor custom
extensions upstream, and that will encourage vendors to work upstream.  We
already have support for SiFive custom extensions on
the users/riscv/binutils-integration-branch.  The plan was to move that to
the master branch after the last release, but Nelson has been busy and
hasn't gotten around to it yet.  Ventana custom extensions are just more of
the same.  Hopefully we can also get Alibaba/T-Head and others to add their
custom extensions upstream too.

If you don't want custom extensions, it is easy enough to avoid them by not
enabling them in the arch string.  I expect that vendor independent linux
distros will be built without any vendor custom extensions enabled.

Jim