[PATCH] x86: Disable XCHG to MOV optimization

[Jan Beulich]

On 14.07.2026 05:03, Alan Modra wrote:
> On Mon, Jul 13, 2026 at 05:20:14PM +0200, Jan Beulich wrote:
>> On 13.07.2026 17:10, H.J. Lu wrote:
>>> On Mon, Jul 13, 2026 at 11:03 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 13.07.2026 14:08, H.J. Lu wrote:
>>>>> I am going to check this patch into master as well as 2.47 branch.
>>>>> I added optimize_for_unsafe, which is 0, and moved XCHG to MOV
>>>>> optimization under it.  We can add something like -Ounsafe later.
>>>>
>>>> But this is wrong, the optimization itself isn't unsafe. Please can we
>>>
>>> You can change it to a different name.  But -O on master must work with
>>> today's valgrind.
>>
>> That's your position. I continue to fail to see why -O needs to work on
>> anything (valgrind or not) that depends on getting to see specific
>> encodings for certain insns. Such uses of -O are simply wrong. Undoing
>> the change on the branch is, as previously indicated, merely to give them
>> some time to adjust their machinery.
> 
> x86 does have multiple encodings for the same instruction.  For
> example, "mov %al,%bl" in att mode can be encoded as 88 c3 or 8a d8.
> Fun trivia: this can and has been used to encode secret messages in
> x86 code, one bit of data in each gpr to gpr move.
> 
> Another example, in 32-bit att "mov 0,%eax" can be encoded as
> a1 00 00 00 00 or 8b 05 00 00 00 00.  Programmers would likely be
> upset, and rightly so, if gas chose the second longer encoding.
> 
> "xchg %eax,%eax" can also be encoded two ways, 90 or 87 c0.  Most
> people reading this list would recognise the first as also being the
> encoding for an x86 "nop" instruction.
> 
> FWIW, my opinion is that "xchg %ecx,%ecx" and the like are special
> encodings of nops.  Just as gas assumes the programmer knows what they
> are doing and does not remove a "nop", gas also should not change a
> special nop into some other form of nop.

If we followed that, we should undo this optimization altogether, and
perhaps tweak a few others (effectively-NOP forms of LEA come to mind).
Putting it under the guard of a variable named
optimize_for_disabled_optimizations (which isn't even a boolean) is
definitely unhelpful.

Jan