[PATCH] x86: Disable XCHG to MOV optimization

[Alan Modra]

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.

-- 
Alan Modra