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

Jan Beulich via Valgrind-developers <valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> Mon, 27 Jul 2026 09:13:45 +0200
Newsgroups gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils
Message-ID <[email protected]>
On 24.07.2026 14:11, Maciej W. Rozycki wrote:
> On Mon, 20 Jul 2026, Michael Matz 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 
> 
>  Sure, it is a peculiarity of the x86 instruction set known to me since 
> forever, and it has always been the case that x86 assemblers choose the 
> shortest encoding for the requested operation (there's some redundancy for 
> address expressions with the addition of the SIB encodings too), although 
> for corner cases there's no way I know of to express the requirement to 
> use a particular machine instruction, e.g.
> 
> 	rcll	$1, %eax
> 
> either modifies or preserves OF depending on the opcode used,

Are you sure about this? Both an old i486 paper manual and the current SDM
refer to COUNT (nowadays COUNT & COUNTMASK) being 1. There's no tying to a
particular encoding afaics.

> and one may 
> need either semantics depending on the circumstances, but no assembler I 
> know of gives the programmer choice here.

I think I did fix this at some point, by making

	rcl	$one, %eax
	.equ one, 1

work. Or maybe I'm misremembering and it has always worked.

Various other cases were also addresses by adding pseudo-prefixes to
allow control.

Jan