Re: [PATCH] x86/asm: Switch clflush alternatives to use %a address operand modifier

[Uros Bizjak]

On Wed, Mar 18, 2026 at 4:03 PM David Laight
<david.laight.linux@xxxxxxxxx> wrote:
>
> On Wed, 18 Mar 2026 10:08:11 +0100
> Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
>
> > The inline asm used with alternative_input() specifies the address
> > operand for clflush with the "a" input operand constraint and
> > explicit "(%[addr])" dereference:
> >
> >     "clflush (%[addr])", [addr] "a" (addr)
> >
> > This forces the pointer into %rax and manually encodes the memory
> > operand in the template. Instead, use the %a address operand
> > modifier and relax the constraint from "a" to "r":
> >
> >     "clflush %a[addr]", [addr] "r" (addr)
> >
> > This lets the compiler choose the register while generating the
> > correct addressing mode.
>
> Aren't these two independent changes?

I was hoping I can put a trivial "a" -> "r" change under the "also
..." change. OTOH, let's change the summary to "x86/asm: Improve
clflush alternatives assembly", that will also handle your proposed
addition of "memory" clobber.

> %a saves you having to know how to write the memory reference for the
> architecture - so is the same as (%[addr]) (assuming att syntax).
> I think the assembler handles the one 'odd' case of (%rbp).

Yes, it does, and also fixes another 'odd' case of (%r13).

> Was there ever a reason for using "a" rather than "r" - it seems an
> unusual choice.

Probably just an oversight due to a follow-up __monitor() that wants
its operand in %rax.

> I also think there should be a "memory" clobber - but it probably
> makes no difference for these two cases.

Hm, I think this is a good proposal. The pointer in the register is
invisible to the compiler memory tracker, so the compiler is free to
schedule (potentially related!) memory access around clflush. The
clobber doesn't make a difference in this particular case, but should
be there nevertheless as a memory read/write barrier.

Thanks,
Uros.