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

On 15.07.2026 09:37, H.J. Lu wrote:
> On Wed, Jul 15, 2026 at 2:23 PM Jan Beulich <[email protected]> wrote:
>>
>> 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.
>>
> 
> Many optimizations have been implemented without any explicit
> rules.   So far we only run into the "XCHG to MOV" issue.   We
> are having this discussion only because the "XCHG to MOV"
> optimization wasn't disabled fast enough.
> 
> The only rule for me is that -O can be used safely on any applications.

In which case we need to rip out all optimizations (assuming you mean all
forms of -O, which I think you do, since elsewhere you said the same more
explicitly also for e.g. -Os).

You did notice though that I'm not the only one who isn't sharing this
position of yours. Optimization _can_ break code using trickery. That's
to be expected, and people playing tricks need to stay away from enabling
optimization. We simply can't make that "safe".

Jan