[PATCH 11/18] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore
Mark Brown
broonie at kernel.org
Tue May 26 09:28:21 PDT 2026
On Thu, May 21, 2026 at 02:25:49PM +0100, Mark Rutland wrote:
> Regardless of whether the vector registers are saved in FPSIMD or SVE
> format, we store FPSR and FPCR in user_fpsimd_state::{fpsr,fpcr}.
...
> Note that the SVE assembly sequence for restoring FPCR uses an
> unconditional write to FPCR. The plain FPSIMD assembly sequence has used
> a conditional write to FPCR since 2014 in commit:
> 5959e25729a5 ("arm64: fpsimd: avoid restoring fpcr if the contents haven't change")
> ... but this was not followed for the SVE restore assembly implemented
> in 2017 in commit:
> 1fc5dce78ad1 ("arm64/sve: Low-level SVE architectural state manipulation functions")
> ... so I've assumed that this doesn't actually matter in practice, and
> implemented the C version matching the existing SVE assembly.
> For the moment, fpsimd_save_state() and fpsimd_load_state() are left
> as-is with their own logic to save/restore FPSR and FPCR. This will be
> unified in subsequent patches.
There is a possibility that it only matters for older, FPSIMD only CPUs
or just that nobody got round to benchmarking this on physical CPUs with
SVE and in fact a similar optimisation is also useful there. I'm a bit
wary of dropping the optimisation without any verification of the
performance impact, but equally I'm not aware of a specific benchmark
that showed the impact or even if there was one in the first place. The
changelog sounds like the optimisation might've been written based on
inspection alone, I don't know if anyone will remember more than a
decade later.
Having said all that given that a conditional update is simple to
implement in C it seems safer to add one in the SVE path than to drop
it from the FPSIMD path.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260526/e2785d72/attachment.sig>
More information about the linux-arm-kernel
mailing list