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

On 20.07.2026 08:47, H.J. Lu wrote:
> On Mon, Jul 20, 2026 at 2:43 PM Jan Beulich <[email protected]> wrote:
>>
>> On 17.07.2026 22:24, H.J. Lu wrote:
>>> On Fri, Jul 17, 2026 at 7:02 PM Jan Beulich <[email protected]> wrote:
>>>>
>>>> On 17.07.2026 11:22, H.J. Lu wrote:
>>>>> On Fri, Jul 17, 2026 at 4:44 PM Jan Beulich <[email protected]> wrote:
>>>>>>
>>>>>> On 15.07.2026 10:17, H.J. Lu wrote:
>>>>>>> GNU assembler is used by GCC to generate binaries.  GCC may not
>>>>>>> always generate the optimal encoding.   That is why I added -O to
>>>>>>> assembler in the first place.  There is no point in adding it if it isn't safe.
>>>>>>> We can't break applications because of some assembler optimizations.
>>>>>>
>>>>>> So this kind of thing will break with any optimization changing encoding
>>>>>> size:
>>>>>>
>>>>>>         test    eax, eax
>>>>>>         jnz     $+9
>>>>>>         test    rcx, 0x21
>>>>>>
>>>>>> (Intel syntax for all examples, as that's what I'm more used to.)
>>>>>>
>>>>>> This clearly breaks as well:
>>>>>>
>>>>>>         test    eax, eax
>>>>>>         jz      1f+2
>>>>>> 1:      test    bx, 0x21
>>>>>>
>>>>>> As does this:
>>>>>>
>>>>>>         test    ecx, ecx
>>>>>>         jz      $+4
>>>>>>         mov     rcx, 0xc9634890
>>>>>>
>>>>>> While all of these may look contrived, I've seen code (not written by
>>>>>> myself) doing similar things. A construct branching into the middle of
>>>>>> an insn was (transiently) even considered to address one of the many
>>>>>> speculation issues we've seen over the last 8+ years.
>>>>>
>>>>> That is why I meant case by case.
>>>>
>>>> Well, I've now given you a case where the very first optimizations that
>>>> were introduced break. Are you now agreeing that we need to rip them all
>>>
>>> The primary goal of -O is to have shorter encoding.  Clearly you shouldn't
>>> use it on codes which depend on encoding length.   In this case, -O0 or
>>> .noopt should be used to totally turn off encoding optimization.
>>
>> Which then would also go as far as the use in valgrind. Feels like we're
>> moving in circles.
>>
>> See how Alan has proposed an objective rule: Leave no-operation patterns
>> alone. As iirc indicated in reply there, I'm intending to make a patch to
> 
> This should work for valgrind.

You're still tied to this particular case. Yes, it'll help their present case.
Yet that it not the motivation for the rule. And there may be another form of
optimization later on that may break valgrind again. I'd like to avoid having
all the same discussion another time, hence why I'm demanding objective
criteria.

>> that effect. There's one other patch I'd like to finish and submit first,
>> as leveraging what it does may then become an option.
>>
>>>> out again? Or else is "case by case" yet more subjective than I understood
>>>> so far, perhaps as in "H.J.'s optimizations are always okay, while Jan's
>>>> never are"?
>>>
>>> I assume that you didn't mean it.
>>
>> Well, short of any objective criteria, that's how I can't help feeling it
>> is being treated right now.
> 
> Were you implying that "XCHG to MOV optimization" was
> the only optimization you have done so far?   That is what
> "while Jan's never are" tells me.

It's not the first time we discuss an optimization, iirc. Sadly, in cases
where I explicitly request feedback, I'm generally getting none (true not
just for optimizations, though).

Jan