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

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.

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

-- 
H.J.