[PATCH] x86: Disable XCHG to MOV optimization

[Jiang, Haochen]

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

Thx,
Haochen