[PATCH] x86: Disable XCHG to MOV optimization

[H.J. Lu]

On Wed, Jul 15, 2026 at 4:42 PM Jiang, Haochen <haochen.jiang@intel.com> wrote:
>
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Wednesday, July 15, 2026 4:20 PM
> >
> > On 15.07.2026 10:17, H.J. Lu wrote:
> > > 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:
> > >>> 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.
> >
>
> I believe the very first problem here is if the application is doing what it should
> do. I don't think Valgrind is doing the safe things by redirecting the instruction
> meaning. We could not guarantee their self-defined behavior to be consistent
> version to version. And we should not judge if an optimization is safe or not due
> to unsafe behavior by other applications.
>
> So that is why I suppose we still need a clearer rule for future work. It is always
> frustrating for someone doing the job but thrown into rubbish bin because of
> some unsafe behavior from other applications that sometimes we don't even
> know and we could not control.
>

Assembler optimization essentially second-guesses what the programmers
or compilers really want to do.  So far we have guessed most correctly
with only one exception so far.  When you ask for the second-guessing
rules, it is hard to have a complete list.  If the list is too narrow,
it limits what
we can optimize.  If the list is wide open, it doesn't mean much.

As for the wasted efforts, no one can second-guess 100% correctly.
If you can't live with it, don't second-guess.

-- 
H.J.