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

[Michael Matz]

Hello,

On Thu, 2 Jul 2026, Mark Wielaard wrote:

>    This instruction decoder can decode three special instructions     
>    which mean nothing natively (are no-ops as far as regs/mem are     
>    concerned) but have meaning for supporting Valgrind.  A special    
>    instruction is flagged by the 16-byte preamble 48C1C703 48C1C70D   
>    48C1C73D 48C1C733 (in the standard interpretation, that means: rolq
>    $3, %rdi; rolq $13, %rdi; rolq $61, %rdi; rolq $51, %rdi).         
>    Following that, one of the following 3 are allowed (standard       
>    interpretation in parentheses):                                    
>                                                                                 
>       4887DB (xchgq %rbx,%rbx)   %RDX = client_request ( %RAX )       
>       4887C9 (xchgq %rcx,%rcx)   %RAX = guest_NRADDR                  
>       4887D2 (xchgq %rdx,%rdx)   call-noredir *%RAX                   
>       4887F6 (xchgq %rdi,%rdi)   IR injection                         

So, a future version of the header should use .byte instead of menmonics.  
That doesn't yet solve all the vendored versions in 3rd party software, so 
...

> So we need a solution that prevents this particular xchg to mov 
> translation (at least for same register ones) even if the sequence is 
> compiled with gas optimizations.

... it seems more kind if valgrind just accepts the alternative variants 
that GAS emits now, so that software that is so compiled Just Works.

Making GAS not do the transformation is fairly awkward: it would have 
to detect the valgrind preamble (there's no other hint) and then disable 
it.  Detecing the preamble requires infrastructure that isn't hard to do, 
but is also not yet existing: it requires some tracking of state over 
multiple instructions, that don't inherently have state as far as the 
assembler is concerned: simple reg-reg insns.


Ciao,
Michael.