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

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
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.

Jan