[PATCH] x86: Disable XCHG to MOV optimization

[Jiang, Haochen]

> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Tuesday, July 14, 2026 6:02 PM
> 
> On Tue, Jul 14, 2026 at 1:55 PM Jan Beulich <jbeulich@suse.com> 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 <jbeulich@suse.com>
> 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.
> 

I have no objection to revert or move this optimization to another option
for now. But I am still confused after that long thread and this and would
like to ask for an answer here. What is a safe optimization?

In Valgrind case, they are redirecting some nop encoding to another
meaning and using -O. I personally don't think it is a legal usage and should
be prohibited or at least notice toolchain when doing that. But since it
has been widely used, they report that and we need to undo the change.
But there are tons of applications in the world, nobody knows if anyone
has redirected something else and the optimization we do unintentionally
break them. Thus, all the optimizations changing the encoding could be
unsafe. It is not ideal to rely on others reporting to us to determine if
something is safe or not.

We really need a clear answer for the bound. It seems vague for me.

Thx,
Haochen