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

On Mon, 20 Jul 2026, Michael Matz 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 

 Sure, it is a peculiarity of the x86 instruction set known to me since 
forever, and it has always been the case that x86 assemblers choose the 
shortest encoding for the requested operation (there's some redundancy for 
address expressions with the addition of the SIB encodings too), although 
for corner cases there's no way I know of to express the requirement to 
use a particular machine instruction, e.g.

	rcll	$1, %eax

either modifies or preserves OF depending on the opcode used, and one may 
need either semantics depending on the circumstances, but no assembler I 
know of gives the programmer choice here.

 I think there's a line to be drawn though between chosing among different 
opcodes that express the same machine operation and substituting another 
machine operation.  It is an assembly language dialect after all and not a 
high-level language.

> happily rewrites even memory loads into lea since a long time.  That GAS 

 Weird, by following this path you could do almost any code transformation 
by observing that operands turn out constant at link time.  But that seems 
to be the purpose of LTO and not a task reasonably expected to be done by 
the linker itself.

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

 As noted above the choice used to be limited to the machine operation 
requested as per Intel documentation and x86 assembly language programming 
manuals and code writers have been prepared to handle that.

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

 Or possibly have a way to request a particular opcode without having to 
encode the whole machine instruction by hand.

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

 If it forces software maintainers to rewrite their inline assembly with 
handcoded machine instructions because distributions may set `-Wa,-O' in 
CFLAGS, then I think it's the wrong direction anyway.  And likewise making 
up for any compiler's deficiency in code generation.

  Maciej