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