Re: [PATCH] x86: Disable XCHG to MOV optimization

On Tue, Jul 14, 2026 at 07:55:35AM +0200, Jan Beulich wrote:
> On 14.07.2026 05:03, Alan Modra wrote:
> > On Mon, Jul 13, 2026 at 05:20:14PM +0200, Jan Beulich wrote:
> >> On 13.07.2026 17:10, H.J. Lu wrote:
> >>> On Mon, Jul 13, 2026 at 11:03 PM Jan Beulich <[email protected]> wrote:
> >>>>
> >>>> On 13.07.2026 14:08, H.J. Lu wrote:
> >>>>> I am going to check this patch into master as well as 2.47 branch.
> >>>>> I added optimize_for_unsafe, which is 0, and moved XCHG to MOV
> >>>>> optimization under it.  We can add something like -Ounsafe later.
> >>>>
> >>>> But this is wrong, the optimization itself isn't unsafe. Please can we
> >>>
> >>> You can change it to a different name.  But -O on master must work with
> >>> today's valgrind.
> >>
> >> That's your position. I continue to fail to see why -O needs to work on
> >> anything (valgrind or not) that depends on getting to see specific
> >> encodings for certain insns. Such uses of -O are simply wrong. Undoing
> >> the change on the branch is, as previously indicated, merely to give them
> >> some time to adjust their machinery.
> > 
> > x86 does have multiple encodings for the same instruction.  For
> > example, "mov %al,%bl" in att mode can be encoded as 88 c3 or 8a d8.
> > Fun trivia: this can and has been used to encode secret messages in
> > x86 code, one bit of data in each gpr to gpr move.
> > 
> > Another example, in 32-bit att "mov 0,%eax" can be encoded as
> > a1 00 00 00 00 or 8b 05 00 00 00 00.  Programmers would likely be
> > upset, and rightly so, if gas chose the second longer encoding.
> > 
> > "xchg %eax,%eax" can also be encoded two ways, 90 or 87 c0.  Most
> > people reading this list would recognise the first as also being the
> > encoding for an x86 "nop" instruction.
> > 
> > FWIW, my opinion is that "xchg %ecx,%ecx" and the like are special
> > encodings of nops.  Just as gas assumes the programmer knows what they
> > are doing and does not remove a "nop", gas also should not change a
> > special nop into some other form of nop.
> 
> If we followed that, we should undo this optimization altogether,

Yes.  I'm of the opinion that nops should be treated with care,
precisely because they "do nothing".  They can be used to implement a
special purpose machine instruction that on newer hardare actually
does something, but on older hardware is a nop.  One example that I'm
familiar with is the power9 "exser" instruction, which on older
hardware does nothing.  (The encoding is ori r31,r31,0, and the usual
powerpc nop is ori r0,r0,0.)

> and
> perhaps tweak a few others (effectively-NOP forms of LEA come to mind).

Perhaps.  I don't have a strong opinion on those, although I lean toward
excluding lea (%rM),%rN from the mov transformation when rM is equal
to rN.  I do think extreme care should be taken with instructions that
are closely related to the architecture "nop" instruction.

> Putting it under the guard of a variable named
> optimize_for_disabled_optimizations (which isn't even a boolean) is
> definitely unhelpful.
> 
> Jan

-- 
Alan Modra