[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