[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ba1c1717-5a21-4f67-a00a-6786256a0156@app.fastmail.com>
Date: Sun, 04 Oct 2026 20:18:38 +0200
From: Alex Rønne Petersen <alex@...xrp.com>
To: "Rich Felker" <dalias@...c.org>, "Alexander Monakov" <amonakov@...ras.ru>,
musl@...ts.openwall.com
Subject: Re: [PATCH] riscv: declare all vector registers as clobbers of syscalls
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.
> 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.
As far as I can tell, __riscv_v has the exact same compiler version problems as __riscv_vector that I listed in my earlier message.
> - 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.
I don't think there even is a predefined macro for LTO, FWIW.
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.
