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

[Jan Beulich]

On 14.07.2026 13:40, Mark Wielaard wrote:
> Hi H.J.
> 
> On Tue, Jul 14, 2026 at 07:10:19PM +0800, H.J. Lu wrote:
>> On Tue, Jul 14, 2026 at 6:33 PM Mark Wielaard <mark@klomp.org> wrote:
>>> On Mon, Jul 13, 2026 at 06:05:56PM +0800, H.J. Lu wrote:
>>>> -On/-Os I added to assembler which should be 100% safe.  If you can't
>>>> or won't make it 100% safe, you can add another option to perform unsafe
>>>> optimization.
>>>
>>> It looks like you need a clear definition of "safe" and "unsafe". And
>>> there are probably multiple different ones depending on context.
>>> e.g. you could provide an option that makes it "safe" for the user to
>>> rely on the instruction length. Or a guarantee that the code will
>>> always use the shortest encoding. Another for not trying to optimize
>>> away "redundent" encoding prefixes. Or removing "nop" sequences. Or
>>> one that explicitly changes any nop sequences to the most efficient
>>> one (for a particular length), etc.
>>>
>>> Just make sure you agree on what "safe" and "unsafe" mean for
>>> particular optimization levels/switches. And document them so the user
>>> knows what they can expect when enabling the "optimization".
>>>
>> By "safe", I mean an optimization won't break applications.   The
>> most x86 assembler optimizations are for shorter encodings.   They
>> shouldn't make an application stop working as expected.
> 
> That is not a very good definition because it doesn't specify what
> kind of transformations are done. Every transformation might "break" a
> specific application or stop it they don't expect a particular
> "optimization". You have to be explicit about the kind of
> transformation that is done by a particular optimization so the user
> can expect them.
> 
> What you could do for example is limit optimizations to specific
> instruction sets. If I understand your original motivation it was to
> use more efficient/shorter sse encodings. Why not put those under a
> specific -Osse option for example? Then it is immediately clear why to
> use that particular optimization without mixing it with any others.

This wouldn't scale very well, I'm afraid. Having fewer options certainly
has its benefits. And as before - if someone turns on optimization, they
have to be certain they don't use any trickery anywhere. Any games being
played or any specific encodings expected may break when any of the -O
options are used.

Jan