Re: [PATCH] x86: Disable XCHG to MOV optimization
Jan Beulich <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
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 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"? Jan