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

[Jan Beulich]

On 03.07.2026 08:32, Paul Floyd wrote:
> On 2026-07-03 08:23, Jan Beulich wrote:
>> I don't expect so. In fact, my take is that -O... should not be used on
>> compiler generated code. The compiler should do whatever optimizations
>> are possible / sensible, and it should not emit code which can (easily)
>> further be optimized. (Easily because the assembler really only does
>> very simple and pretty obvious transformations.)
>>
>> I can see that there may be a desire to optimize asm()-generated code.
>> That imo shouldn't be done by passing -Wa,-O... but rather by some
>> other, to be invented machinery. (We could tie it to the #APP / #NO_APP
>> markers that the compiler emits, for example.)
> 
> Well this does look like a gratuitous optimisation to me. We chose these 
> sequences because we believed that no compiler or sensible person would 
> ever use them.
> 
> Other than Valgrind do you have any real world examples of benefits of 
> making this change?

I can't concretely point out an instance of this pattern, but especially
BIOS code that I've seen over the years comes with all sorts of
inefficiencies. Furthermore, heavily macro-ized code can run into
situations like this one, and having the assembler do the "enlightening"
may then be preferred over adding special cases into the macros.

More generally: I think this is the wrong question to ask. With the
introduction of optimization many years ago, code having no control over
the options passed to gas should be written in a way that is immune to
_any_ optimizations an assembler may ever do. Which then may require
resorting to .byte or alike, as Michael did suggest. (Alternatively it
should be made clear to consumers of that code that they may not enable
optimization.)

Jan