[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20261015003400.GT23438@brightrain.aerifal.cx>
Date: Wed, 14 Oct 2026 20:34:00 -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 Thu, Oct 15, 2026 at 02:17:34AM +0200, Alex Rønne Petersen wrote:
> On Thu, Oct 15, 2026, at 02:04, Rich Felker wrote:
> > 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)
> > ...
>
> This sounds workable to me. To be safe, per the compiler versions I
> listed earlier in the thread, we should test for either vxrm or
> vxsat in the clobbers. I don't think we need to test the full list.
That's probably ok in practice, but it might make sense to just test
the exact same thing we intend to use in the source.
> Will __attribute__((__noinline__)) overrule the static inline?
I think so but I guess that needs checking. We could move the inline
out to SYSCALL_FUNCTION_ATTRS if needed.
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.
