Re: [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms

On 13.07.2026 11:57, H.J. Lu wrote:
> On Mon, Jul 13, 2026 at 5:28 PM Mark Wielaard <[email protected]> wrote:
>> On Mon, Jul 13, 2026 at 08:09:23AM +0200, Jan Beulich wrote:
>>> On 12.07.2026 17:37, Mark Wielaard wrote:
>>>> I am not sure I understand why you want inline assembly excluded. Yes,
>>>> inline assembly is "hand-written", but only because there was no exact
>>>> way to make the compiler produce a specific sequence or encoding of
>>>> some instructions. How about something like:
>>>>
>>>> "Assembler optimization is intended primarily for hand-written
>>>> assembly files, not for use with compiler generated code (or inline
>>>> assembly crafted explicitly to produce a specific instruction sequence
>>>> or encoding).  If you notice any effects on compiler generated code,
>>>> please consider raising a bug against the compiler about a missed
>>>> optimization.  Note, however, that this does not extend to there
>>>> possibly being effects on code originating from hand-written assembly
>>>> code embedded as a whole into a higher-level language compiler."
>>>
>>> Well. You've seen H.J.'s reply, haven't you? His take is that -O very much
>>> is for compiler generated code. As just indicated on another thread, what
>>> is needed here first is an agreed upon understanding what we want to
>>> optimize (for). Intentions originally weren't made sufficiently clear, and
>>> hence views looks to have heavily diverged.
>>
>> OK, but lets document that then so people don't accidentially use -O
>> without knowing that the option doesn't have clear semantics. How
>> about simply:
>>
>> "Assembler optimization is currently an experimental feature that
>> might result in changing instruction encoding, replacement of
>> instructions by equivalent ones or removal of instructions that could
>> be seen as nops. Don't use it when you have code that depends on the
>> exact assembler instruction encodings."
> 
> GNU assembler is used by GCC to generate binaries.  Assembler
> optimizations should be 100% safe for all applications, hand-written
> codes or compiler generated codes.

It cannot be. People playing tricks have to stay away from enabling
optimization. What we're seeing here is a "mild" trick, but as we can see
bad enough. Something like .byte-encoded opcode prefixes with e.g. Jcc
over them cannot ever be safe to optimization.

Jan