From: Mark Rutland <mark.rutland@arm•com>
To: Vladimir Murzin <vladimir.murzin@arm•com>
Cc: linux-arm-kernel@lists•infradead.org, kvmarm@lists•linux.dev,
broonie@kernel•org, catalin.marinas@arm•com, james.morse@arm•com,
maz@kernel•org, oupton@kernel•org, tabba@google•com,
will@kernel•org
Subject: Re: [PATCH 12/18] arm64: fpsimd: Move fpsimd save/restore inline
Date: Wed, 27 May 2026 16:34:57 +0100 [thread overview]
Message-ID: <ahcPITrHKBgAHGkP@J2N7QTR9R3.cambridge.arm.com> (raw)
In-Reply-To: <c5ba3af9-08b2-4be2-b9f5-58a925f0b050@arm.com>
On Wed, May 27, 2026 at 03:49:18PM +0100, Vladimir Murzin wrote:
> On 5/21/26 14:25, Mark Rutland wrote:
> > +static inline void fpsimd_save_vregs(struct user_fpsimd_state *state)
> > +{
> > + instrument_write(state->vregs, sizeof(state->vregs));
> > + asm volatile(
> > + __FPSIMD_PREAMBLE
> > + " stp q0, q1, [%[vregs], #16 * 0]\n"
> > + " stp q2, q3, [%[vregs], #16 * 2]\n"
> > + " stp q4, q5, [%[vregs], #16 * 4]\n"
> > + " stp q6, q7, [%[vregs], #16 * 6]\n"
> > + " stp q8, q9, [%[vregs], #16 * 8]\n"
> > + " stp q10, q11, [%[vregs], #16 * 10]\n"
> > + " stp q12, q13, [%[vregs], #16 * 12]\n"
> > + " stp q14, q15, [%[vregs], #16 * 14]\n"
> > + " stp q16, q17, [%[vregs], #16 * 16]\n"
> > + " stp q18, q19, [%[vregs], #16 * 18]\n"
> > + " stp q20, q21, [%[vregs], #16 * 20]\n"
> > + " stp q22, q23, [%[vregs], #16 * 22]\n"
> > + " stp q24, q25, [%[vregs], #16 * 24]\n"
> > + " stp q26, q27, [%[vregs], #16 * 26]\n"
> > + " stp q28, q29, [%[vregs], #16 * 28]\n"
> > + " stp q30, q31, [%[vregs], #16 * 30]\n"
> > + : "=Q" (state->vregs)
> > + : [vregs] "r" (state->vregs)
>
> Missing "memory" clobber here?
Here the "=Q" constraint is sufficient.
The "=Q" output constraint describes that the operand is written to but
the old value is not read. It behaves like an "=m" constraint, but
places the base address in a single register without any offset (and no
writeback addressing mode). Here it applies to the entirety of the
vregs array.
See https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html :
| Q
| A memory address which uses a single base register with no offset
We generally prefer to use "Q" constraints rather than memory clobbers
where possible, since it gives the compiler more freedom (e.g. due to
*not* clobbering unrelated memory locations).
The "Q" constraint causes the output to be formatted as a memory address
(e.g. "[x0]"), so to be able to apply an offset we need a separate "r"
constraint to get the base register. It doesn't matter whether the
compiler happens to use a different register for that (and in practice
compilers realise they can use the register allocated for the "Q"
conrstraint).
Unfortunately we can't use "Q" for the scalable registers, since the
size isn't known at compile time, and the simplest option for those is
to use a memory clobber.
[...]
> > +static inline void fpsimd_load_vregs(const struct user_fpsimd_state *state)
> > +{
> > + instrument_read(state->vregs, sizeof(state->vregs));
> > + asm volatile(
> > + __FPSIMD_PREAMBLE
> > + " ldp q0, q1, [%[vregs], #16 * 0]\n"
> > + " ldp q2, q3, [%[vregs], #16 * 2]\n"
> > + " ldp q4, q5, [%[vregs], #16 * 4]\n"
> > + " ldp q6, q7, [%[vregs], #16 * 6]\n"
> > + " ldp q8, q9, [%[vregs], #16 * 8]\n"
> > + " ldp q10, q11, [%[vregs], #16 * 10]\n"
> > + " ldp q12, q13, [%[vregs], #16 * 12]\n"
> > + " ldp q14, q15, [%[vregs], #16 * 14]\n"
> > + " ldp q16, q17, [%[vregs], #16 * 16]\n"
> > + " ldp q18, q19, [%[vregs], #16 * 18]\n"
> > + " ldp q20, q21, [%[vregs], #16 * 20]\n"
> > + " ldp q22, q23, [%[vregs], #16 * 22]\n"
> > + " ldp q24, q25, [%[vregs], #16 * 24]\n"
> > + " ldp q26, q27, [%[vregs], #16 * 26]\n"
> > + " ldp q28, q29, [%[vregs], #16 * 28]\n"
> > + " ldp q30, q31, [%[vregs], #16 * 30]\n"
> > + :
> > + : "Q" (state->vregs),
> > + [vregs] "r" (state->vregs)
>
> Missing "memory" clobber here?
Same story as for fpsimd_save_vregs() above, except that here the "Q"
input constraint describes that the entirety of the operand is read from
but not written to.
Mark.
next prev parent reply other threads:[~2026-05-27 15:35 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 13:25 [PATCH 00/18] arm64+KVM: FPSIMD/SVE/SME cleanups Mark Rutland
2026-05-21 13:25 ` [PATCH 01/18] KVM: arm64: Don't include <asm/fpsimdmacros.h> Mark Rutland
2026-05-26 14:18 ` Mark Brown
2026-05-27 10:10 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 02/18] KVM: arm64: Don't override FFR save/restore argument Mark Rutland
2026-05-26 14:27 ` Mark Brown
2026-05-27 10:16 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 03/18] KVM: arm64: pkvm: Save host FPMR in host cpu context Mark Rutland
2026-05-27 10:29 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 04/18] KVM: arm64: pkvm: Remove struct cpu_sve_state Mark Rutland
2026-05-27 11:58 ` Vladimir Murzin
2026-05-27 16:02 ` Mark Rutland
2026-05-27 16:11 ` Vladimir Murzin
2026-05-28 15:09 ` Mark Rutland
2026-05-28 15:12 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 05/18] arm64: fpsimd: Fold sve_init_regs() into do_sve_acc() Mark Rutland
2026-05-26 15:28 ` Mark Brown
2026-05-27 12:05 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 06/18] arm64: fpsimd: Remove sve_set_vq() and sme_set_vq() Mark Rutland
2026-05-26 15:42 ` Mark Brown
2026-05-27 12:50 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 07/18] arm64: fpsimd: Use assembler for SVE instructions Mark Rutland
2026-05-26 15:43 ` Mark Brown
2026-05-27 12:58 ` Vladimir Murzin
2026-05-27 16:10 ` Mark Rutland
2026-05-21 13:25 ` [PATCH 08/18] arm64: fpsimd: Use assembler for baseline SME instructions Mark Rutland
2026-05-26 15:45 ` Mark Brown
2026-05-27 13:06 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 09/18] arm64: fpsimd: Move sve_get_vl() and sme_get_vl() inline Mark Rutland
2026-05-26 15:47 ` Mark Brown
2026-05-27 13:18 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 10/18] arm64: sysreg: Add FPCR and FPSR Mark Rutland
2026-05-26 15:55 ` Mark Brown
2026-05-26 16:51 ` Mark Rutland
2026-05-26 16:54 ` Mark Brown
2026-05-21 13:25 ` [PATCH 11/18] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore Mark Rutland
2026-05-26 16:28 ` Mark Brown
2026-05-27 13:51 ` Mark Rutland
2026-05-27 14:13 ` Mark Brown
2026-05-27 16:13 ` Mark Rutland
2026-05-27 13:44 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 12/18] arm64: fpsimd: Move fpsimd save/restore inline Mark Rutland
2026-05-26 16:44 ` Mark Brown
2026-05-28 16:15 ` Mark Rutland
2026-05-28 16:39 ` Mark Brown
2026-05-27 14:49 ` Vladimir Murzin
2026-05-27 15:34 ` Mark Rutland [this message]
2026-05-27 16:13 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 13/18] arm64: fpsimd: Use opaque type for SVE state Mark Rutland
2026-05-26 16:53 ` Mark Brown
2026-05-28 9:45 ` Vladimir Murzin
2026-05-28 16:25 ` Mark Rutland
2026-05-21 13:25 ` [PATCH 14/18] arm64: fpsimd: Use opaque type for SME state Mark Rutland
2026-05-26 16:56 ` Mark Brown
2026-05-28 9:51 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 15/18] arm64: fpsimd: Move SVE save/restore inline Mark Rutland
2026-05-27 12:29 ` Mark Brown
2026-05-28 10:39 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 16/18] arm64: fpsimd: Move sve_flush_live() inline Mark Rutland
2026-05-27 12:54 ` Mark Brown
2026-05-27 16:23 ` Mark Rutland
2026-05-28 10:49 ` Vladimir Murzin
2026-05-21 13:25 ` [PATCH 17/18] arm64: fpsimd: Move SME save/restore inline Mark Rutland
2026-05-26 14:08 ` Mark Rutland
2026-05-26 14:39 ` Vladimir Murzin
2026-05-26 15:28 ` Mark Rutland
2026-05-26 16:38 ` Mark Rutland
2026-05-27 9:00 ` Vladimir Murzin
2026-05-29 9:10 ` Mark Rutland
2026-05-28 12:30 ` Vladimir Murzin
2026-05-28 14:39 ` Mark Rutland
2026-05-21 13:25 ` [PATCH 18/18] arm64: fpsimd: Remove <asm/fpsimdmacros.h> Mark Rutland
2026-05-28 13:10 ` Vladimir Murzin
2026-05-27 8:07 ` [PATCH 00/18] arm64+KVM: FPSIMD/SVE/SME cleanups Marc Zyngier
2026-05-27 10:32 ` Mark Rutland
2026-05-27 14:36 ` Will Deacon
2026-05-28 13:21 ` Vladimir Murzin
2026-05-28 16:28 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahcPITrHKBgAHGkP@J2N7QTR9R3.cambridge.arm.com \
--to=mark.rutland@arm$(echo .)com \
--cc=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=james.morse@arm$(echo .)com \
--cc=kvmarm@lists$(echo .)linux.dev \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=maz@kernel$(echo .)org \
--cc=oupton@kernel$(echo .)org \
--cc=tabba@google$(echo .)com \
--cc=vladimir.murzin@arm$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox