[Valgrind-developers] [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms

[Mark Wielaard]

Hi Jan,

On Tue, Jul 14, 2026 at 02:00:10PM +0200, Jan Beulich wrote:
> On 14.07.2026 13:40, Mark Wielaard wrote:
> > That is not a very good definition because it doesn't specify what
> > kind of transformations are done. Every transformation might "break" a
> > specific application or stop it they don't expect a particular
> > "optimization". You have to be explicit about the kind of
> > transformation that is done by a particular optimization so the user
> > can expect them.
> > 
> > What you could do for example is limit optimizations to specific
> > instruction sets. If I understand your original motivation it was to
> > use more efficient/shorter sse encodings. Why not put those under a
> > specific -Osse option for example? Then it is immediately clear why to
> > use that particular optimization without mixing it with any others.
> 
> This wouldn't scale very well, I'm afraid. Having fewer options certainly
> has its benefits. And as before - if someone turns on optimization, they
> have to be certain they don't use any trickery anywhere. Any games being
> played or any specific encodings expected may break when any of the -O
> options are used.

Sure, maybe my "per instruction set" idea is too simplistic, but at
least it is makes more clear to the user what exactly an optimization
does. And you can combine several into a larger set. sse encoding
optimizations might go into -O1 while nop "simplifications" might go
into -O2, etc.

But I think you really cannot just say optimizations have to be "safe"
or tell users they cannot do any "trickery" without defining very
clearly what you mean by that. You might think you know what "safe"
means, or what disallowed "trickery" is. But you will end up with
personal opinions that are very tricky (pun intended) to resolve. It
will just mean nobody will ever use -O because "safe" and "trickery"
are too vague concepts and users will not take the risk to use them
ever.

Cheers,

Mark