[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7754937b-2ad4-493c-abd8-1f6b7c245c05@app.fastmail.com>
Date: Thu, 15 Oct 2026 02:17:34 +0200
From: Alex Rønne Petersen <alex@...xrp.com>
To: "Rich Felker" <dalias@...c.org>
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: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.
Will __attribute__((__noinline__)) overrule the static inline?
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.
