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

[David Laight]

On Wed, 18 Mar 2026 16:45:28 +0100
Uros Bizjak <ubizjak@xxxxxxxxx> wrote:

> 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.

Actually gcc can be quite bad are reverse tracking register requirements.
So forcing 'addr' into %rax for the cflush might actually remove
a register move before the monitor.
Indeed, were it to pick a different register there will always be a
extra register move.
If the value is in a different register (eg from a function call)
then you'll move the register move instruction - but there'll still
be one.

So I suspect this change can never improve the code.

	David

> 
> > 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.
>