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

Hello,

On Mon, 6 Jul 2026, Mark Wielaard wrote:

> >   When changing that piece of code at all, why then not also add the 
> > four cases that's emitted by gas right now?  Be lenient in what you 
> > accept, and all that?
> 
> Because Jan said we cannot rely on what it is optimized to, it might 
> even get optimized away completely because they are technically nops.

Sure, that's why you also want to change valgrind.h to use concrete 
encodings.  Eventually, after many years perhaps, it will then be 
impossible to see any other sequence after the preamble than those we 
already know by then (what GAS or other random assemblers currently and in 
some future years to come can emit).  Until then, yes, you will have to 
play some chase-the-encodings game, but (a) that isn't unknown to valgrind 
anyway :) and (b) it won't occur _that_ often.  I really don't see why one 
would _not_ want to recognize known sequences as a service to users.

Thing is: these kinds of insn-rewrites at assemble time are really not so 
arcane.  On x86(-64) they are mildly unheard of, but e.g. on risc-v 
(converting full to compressed encodings, relaxation-like things), or 
load/store/address relaxations during link time for most archs, are very 
common.  I realize that on _this_ kind of register-only instructions 
rewriting them may seem unexpected, but I really think such expectation 
would be wrong.

> So best we can do is the give_hint () when we detect the user enabled 
> the assembler optimizer and it has mangled our special instruction 
> sequence.

I think give_hint() plus recognizing the current encodings plus using 
hard-coded sequences in valgrind.h is strictly better than just 
give_hint(), so the latter cannot be the best.


Ciao,
Michael.