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

On Tue, Jul 14, 2026 at 1:55 PM Jan Beulich <[email protected]> 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, and
> perhaps tweak a few others (effectively-NOP forms of LEA come to mind).
> Putting it under the guard of a variable named
> optimize_for_disabled_optimizations (which isn't even a boolean) is
> definitely unhelpful.
>

This is done on purpose.  You can even optimize out "XCHG REG64, REG64"
and "MOV REG64, REG64" when optimize_for_disabled_optimizations > N.


-- 
H.J.