[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261004151617.GI23438@brightrain.aerifal.cx>
Date: Sun, 4 Oct 2026 11:16:17 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>,
Alexander Monakov <amonakov@...ras.ru>, musl@...ts.openwall.com
Subject: Re: [PATCH] riscv: declare all vector registers as clobbers
of syscalls
On Sun, Oct 04, 2026 at 12:04:17PM +0200, Szabolcs Nagy wrote:
> * Alex Rønne Petersen <alex@...xrp.com> [2026-10-04 10:08:28 +0200]:
> > On Sun, Oct 4, 2026, at 09:14, Alexander Monakov wrote:
> > > But this is not the right test. You have to diff -E -dM from two runs, one with
> > > -march=rv64gc, another with -march=rv64gcv (and you'll find __riscv_vector).
> >
> > I dismissed __riscv_vector initially because of these findings:
> >
> > * GCC 12 defined __riscv_vector
> > * GCC 13+ understands v0-v31, vl, vtype
> > * GCC 14+ understands vxrm, vxsat
> > * Clang 12 defined __riscv_vector
> > * Clang 13+ understands v0-v31
> > * Clang 18+ understands vl, vtype, vxrm, vxsat
> >
> > So that's all pretty horrible and makes __riscv_vector alone insufficient.
> >
> > However, what we could do is a configure check that errors if __riscv_vector is defined but the clobbers we need aren't accepted.
>
> that should work
>
> fwiw glibc checks __riscv_v for the clobbers which is defined
> in gcc-16 when the abi flag v is present, clang had it forever.
> musl could error on !__riscv_v && __riscv_vector to approximate
> the config check.
Parallel to what I just said for the similar issue with aarch64/sve, I
think we should probably just for have configure force the vector
extension off. This is the approach that has the least chance of
breaking builds in an imminent bugfix release.
Unfortunately, as with sve, this seems like an incomplete solution if
LTO is being used. Fortunately LTO is broken out of the box for other
reasons, so it's not an immediate concern, but I don't like this being
theoretically incorrect with respect to the possibility of LTO
working.
A real solution probably involves:
- If __riscv_v is not defined, forcing vector codegen off at configure
time. This is fully safe for non-LTO, and is a basically the
short-term solution I'm proposing now except only applying it when
the clobbers aren't available.
- Using the clobbers if __riscv_v is defined, if this is sufficient to
know they're present and working.
- If LTO is used, forcing noinline on the syscall functions. I don't
see a safe way to allow inlining them across LTO boundaries on an
arch where the contract for syscall clobbers can change after libc
is built.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
