Re: [PATCH] x86: Disable XCHG to MOV optimization

On 15.07.2026 05:50, H.J. Lu wrote:
> On Wed, Jul 15, 2026 at 10:52 AM Jiang, Haochen <[email protected]> wrote:
>>
>>> From: H.J. Lu <[email protected]>
>>> Sent: Tuesday, July 14, 2026 6:02 PM
>>>
>>> On Tue, Jul 14, 2026 at 1:55 PM Jan Beulich <[email protected]> wrote:
>>>>
>>>> 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 <[email protected]>
>>> 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.
>>>>
>>>
>>> This is done on purpose.  You can even optimize out "XCHG REG64, REG64"
>>> and "MOV REG64, REG64" when optimize_for_disabled_optimizations > N.
>>>
>>
>> I have no objection to revert or move this optimization to another option
>> for now. But I am still confused after that long thread and this and would
>> like to ask for an answer here. What is a safe optimization?
>>
>> In Valgrind case, they are redirecting some nop encoding to another
>> meaning and using -O. I personally don't think it is a legal usage and should
>> be prohibited or at least notice toolchain when doing that. But since it
>> has been widely used, they report that and we need to undo the change.
>> But there are tons of applications in the world, nobody knows if anyone
>> has redirected something else and the optimization we do unintentionally
>> break them. Thus, all the optimizations changing the encoding could be
>> unsafe. It is not ideal to rely on others reporting to us to determine if
>> something is safe or not.

Thanks for calling this out again.

>> We really need a clear answer for the bound. It seems vague for me.
> 
> It is intentionally vague so that the assembler can implement all
> kinds of optimizations.   One can use -O on any applications and
> everything should work as expected.
> 
> The question is what to do when we find out that an optimization
> breaks an application.  We should evaluate it case by case.

No. Some (at least) rough rules need to be established up front.

Jan