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

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.

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

-- 
H.J.