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

"Maciej W. Rozycki" <[email protected]> Mon, 20 Jul 2026 04:08:36 +0100 (BST)
Newsgroups gmane.comp.gnu.binutils,gmane.comp.debugging.valgrind.devel
Message-ID <[email protected]>
On Mon, 6 Jul 2026, Michael Matz wrote:

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

 Well, I don't think we should flush down the drain the notion of an 
assembly language translator being a tool to emit reproducible machine 
instructions from proper assembly code, i.e. not from `.byte' sequences or 
similar pseudo-ops, which actually miss the point where you have different 
instruction encodings to choose from depending on the target to assemble 
for (e.g. regular MIPS vs microMIPS).  And which are largely illegible to 
humans (although I met a person who was capable to intepret 8080 machine 
code instantly in memory).

 And dialects such as RISC-V you mention or MIPS that are keen to make 
transformations provide means to enforce that via pseudo-ops such as `.set 
norelax', `.set noreorder', `.set nomacro' and instruction suffixes for 
compression prevention, such as NOP32, so that critical code pieces can be 
annotated and therefore fixed at the expected form appropriately without 
losing portability or legibility.

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

  Maciej