[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261015000427.GS23438@brightrain.aerifal.cx>
Date: Wed, 14 Oct 2026 20:04:28 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>
Cc: 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 08:18:38PM +0200, Alex Rønne Petersen wrote:
> On Sun, Oct 4, 2026, at 17:16, Rich Felker wrote:
> > 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.
>
> There is no convenient command line syntax for subtracting an
> extension that I can find. We could force a particular -march=...
> value depending on the ABI, but that's going to leave performance on
> the table for things like the B extension, and whatever else.
> Alternatively we could try to work out what -march the compiler is
> using and subtract V from that, but with how RISC-V arch syntax
> works, that sounds like a nightmare.
OK, how would this be for the logic:
At configure time:
For $ARCH matching riscv*, unconditionally attempt to compile a test
TU with an empty asm statement with vector clobbers. This will tell us
if we have the clobbers available for use. If not, add
-DMISSING_RV_V_CLOBBERS or similar to CFLAGS_AUTO.
In riscv*/syscall_arch.h:
#ifndef MISSING_RV_V_CLOBBERS
#define SYSCALL_CLOBBERLIST "memory", "v0", "v1", "v2", ...
#else
#define SYSCALL_CLOBBERLIST "memory"
#if defined(__riscv_v) || defined(__riscv_vector)
#define SYSCALL_FUNCTION_ATTRS __attribute__((__noinline__))
#endif
#endif
#ifndef SYSCALL_FUNCTION_ATTRS
#define SYSCALL_FUNCTION_ATTRS
#endif
SYSCALL_FUNCTION_ATTRS
static inline long __syscall0(long n)
...
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.
