[PATCH] x86: Disable XCHG to MOV optimization

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, July 15, 2026 3:47 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Jiang, Haochen <haochen.jiang@intel.com>; Alan Modra
> <amodra@gmail.com>; Binutils <binutils@sourceware.org>; Nick Clifton
> <nickc@redhat.com>
> Subject: Re: [PATCH] x86: Disable XCHG to MOV optimization
> 
> On 15.07.2026 09:37, H.J. Lu wrote:
> > On Wed, Jul 15, 2026 at 2:23 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 15.07.2026 05:50, H.J. Lu wrote:
> >>> On Wed, Jul 15, 2026 at 10:52 AM Jiang, Haochen
> <haochen.jiang@intel.com> wrote:
> >>>>
> >>>>> 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.
> >>
> >> Thanks for calling this out again.
> >>
> >>>> We really need a clear answer for the bound. It seems vague for me.
> >>>
> >>> It is intentionally vague so that the assembler can implement all
> >>> kinds of optimizations.   One can use -O on any applications and
> >>> everything should work as expected.
> >>>
> >>> The question is what to do when we find out that an optimization
> >>> breaks an application.  We should evaluate it case by case.
> >>
> >> No. Some (at least) rough rules need to be established up front.
> >>
> >
> > Many optimizations have been implemented without any explicit
> > rules.   So far we only run into the "XCHG to MOV" issue.   We
> > are having this discussion only because the "XCHG to MOV"
> > optimization wasn't disabled fast enough.
> >
> > The only rule for me is that -O can be used safely on any applications.
> 
> In which case we need to rip out all optimizations (assuming you mean all
> forms of -O, which I think you do, since elsewhere you said the same more
> explicitly also for e.g. -Os).
> 
> You did notice though that I'm not the only one who isn't sharing this position
> of yours. Optimization _can_ break code using trickery. That's to be expected,
> and people playing tricks need to stay away from enabling optimization. We
> simply can't make that "safe".
> 

As H.J. noted, XCHG→MOV is the only issue we've hit so far. That leans toward handling real problems as they come up rather than writing a full rulebook up front. Many of these optimizations are old and grew over time, so there's probably no single clean rule to pull out of them. Turning off a specific one when it actually breaks something — as we're doing here — seems like the practical path.

Regards,
Lili.

> Jan