[PATCH] x86: Disable XCHG to MOV optimization

[H.J. Lu]

On Wed, Jul 15, 2026 at 3:46 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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).

Please show me a binutils bug report for the broken application because
of using -O with today's binutils master branch.

> 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".
>

GNU assembler is used by GCC to generate binaries.  GCC may not
always generate the optimal encoding.   That is why I added -O to
assembler in the first place.  There is no point in adding it if it isn't safe.
We can't break applications because of some assembler optimizations.


-- 
H.J.