Re: [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms
Michael Matz <[email protected]> Mon, 20 Jul 2026 15:17:33 +0200 (CEST)
| Newsgroups | gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
Hello, On Mon, 20 Jul 2026, Maciej W. Rozycki 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 happily rewrites even memory loads into lea since a long time. That GAS 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. 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. > 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. Ciao, Michael.