Supporting RISC-V Vendor Extensions in the GNU Toolchain
Christoph Müllner
cmuellner@gcc.gnu.org
Fri May 13 12:26:44 GMT 2022
On Fri, May 13, 2022 at 12:58 PM 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.
>
> Not every useful CPU feature can be adopted through run-time dispatching
> (IFUNCs, function multi-versionining).
I fully agree.
Therefore I can just recommend ISA extension designers to discuss the
SW enablement requirements and goals before CPUs are shipped.
In the end it is the responsibility of the CPU vendors to get their extensions
supported upstream and to provide appropriate patches to integrate well
and keep the upstream sources in a maintainable state.
However, I have full trust in the maintainers to make the right judgements
(like they have done in the past).
Thanks,
Christoph
More information about the Gdb-patches
mailing list