Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain

[Philipp Tomsich <philipp.tomsich@vrull.eu>]

On Fri, 13 May 2022 at 12:58, Florian Weimer <fweimer@redhat.com> wrote:
>
> * Christoph Müllner via Binutils:
>
> > I'd like to add two points to this topic and raise two questions.
> >
> > 1) Accepting vendor extensions = avoidance of fragmentation
> >
> > RISC-V implementors are actively encouraged to implement their
> > own ISA extensions. To avoid fragmentation in the SW ecosystem
> > (every vendor maintains a fork of tools, distros and binaries) there
> > needs to be a principle acceptance to get vendor extension support
> > upstream.
>
> If you eventually want portable binaries, it's necessary to converge on
> a small set of widely implemented extensions.  x86 didn't have this, and
> adoption was poor outside specialized libraries (and JIT, of course).
> Yet everything was as upstream as possible (ISA manuals, assemblers,
> compiler intrinsics, even automated adoption by optimizers).  So
> upstreaming is only the first step.

Some of the earlier discussion seems to have mixed two different goals:
1. making the vendor-defined features available to the developer and
ensuring that no unintended consequences (e.g., "accidental"
interlinking) happen, so developers can choose to adopt them (e.g.
through dynamic detection) where appropriate;
2. having widespread adoption for features across
libraries/applications that take advantage of all implemented features

As this is cross-posted to projects that provide the infrastructure,
tools, and plumbing, we should IMO focus on goal #1.
Coming from the RISC-V ISA philosophy, this also makes excellent
sense: after all, RISC-V is (in its purest form) an "ISA construction
kit": one can add extensions or leave extensions off.

For the essential development tools, this flexibility is reflected in
the myriad of combinations that "-march" can have (just consider that
there are 4 distinct Zb[abcs] extensions that add addressing, basic
bit-manipulation, carryless multiplication, and single-bit
operations…).  If individual downstream users see benefits from any of
these (e.g., Zbb for strlen; Zbc for GHASH, …), they will contribute
optimized code-paths under ifunc (or whatever other mechanism a given
library/application uses); however: we first need to have our tools
support these extensions (both standard and vendor-defined) and ensure
that no accidental interlinking happens.

Finally, to enable binary distributions, a basic architecture level
that everyone agrees on (these are being defined at the RISC-V
Foundation under the "Profiles" and "Platforms" umbrellas) provides a
baseline to target that will provide some level of "runs everywhere"
based on such a "small set of widely implemented extensions".

Philipp.