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

Michael Matz <[email protected]> Mon, 20 Jul 2026 15:17:33 +0200 (CEST)
Newsgroups gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils
Message-ID <[email protected]>
Hello,

On Mon, 20 Jul 2026, Maciej W. Rozycki wrote:

> Since this is a new feature retrofitted to the x86 assembly dialect very 
> late in the game I'd question whether a command-line option is the right 
> way to drive it rather than say a new pseudo-op to opt in, which is then 
> tied to the source the writer wants to be optimised for some reason.

That would have been another way, yes.  And I somewhat understand being 
surprised by the transformations, but before I wrote my message I tried to 
reflect a little on that and really came to the conclusion that insn 
rewriting really is nothing new, not even on x86(-64): it uses short 
encodings for jumps, uses a randomly chosen encoding (usually the smaller 
one) for insns that have multiple ones (see Alans mail), and the linker 
happily rewrites even memory loads into lea since a long time.  That GAS 
produces dependable byte-blobs for given textual mnemonics+operands was 
already an illusion in the past.  Its just that the rate of change in that 
area is very low, so when a new change comes it causes surprises.

Obviously we need some opt-out (or, as you say, opt-in) for code blocks 
like on the archs you mentioned.  We would have always needed that, it's 
now just more obvious.

> And indeed I'd question whether it's a good idea to optimise in the 
> first place for a long-established dialect that hasn't been designed 
> with that in mind.  I was quite baffled seeing the patches TBH.

To be also honest: me as well :)  But as explained, after thinking about 
it I think they are sensible.  It's opt-in (-O) and in principle just more 
of what we were doing already.


Ciao,
Michael.