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

On 13.07.2026 11:55, H.J. Lu wrote:
> On Mon, Jul 13, 2026 at 2:09 PM Jan Beulich <[email protected]> wrote:
>>
>> On 12.07.2026 17:37, Mark Wielaard wrote:
>>> Hi Jan,
>>>
>>> On Tue, Jul 07, 2026 at 04:35:27PM +0200, Jan Beulich wrote:
>>>> On 07.07.2026 16:21, Sam James wrote:
>>>>> "Assembler optimization is intended for hand-written code, not to be
>>>>> used on compiler output." which then gives us licence to dispose with
>>>>> bugs reports like this, as opposed to the ambiguity right now.
>>>>
>>>> I fear I wouldn't be happy with making such a statement in doc. For one,
>>>> "intended" is weak enough that people may still think the options are
>>>> worthwhile to use on compiler output. Plus there's the issue with inline
>>>> assembly, which imo can plausibly be subject to optimization. Yet at
>>>> this time we have no way to have optimization "kick in" only on those
>>>> portions.
>>>>
>>>> I could perhaps live with a yet weaker version of what you suggest:
>>>>
>>>> "Assembler optimization is intended primarily for hand-written code.  If
>>>>  you notice any effects on compiler generated code, please consider
>>>>  raising a bug against the compiler.  Note, however, that this does not
>>>>  extend to there possibly being effects on code originating from inline
>>>>  assembly."
>>>
>>> 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.
> 
> There are no hard criterias for assembler optimizations.   In general,
> assembler can re-encode instructions for the same operation to save
> space or improve performance.  We don't ask for performance improvements
> in applications.  However, if we run into significant issues, like
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=34343
> 
> we ask for real applications to show performance improvements to
> justify such drawbacks.

This kind of a model doesn't work, for me at least. If I spend time on
implementing an optimization, I don't want to see the work dropped on the
floor just because some random piece of code has optimization enabled
when it shouldn't have (prior to the code subject to optimization actually
having been audited to be safe against the effects in all possible ways).

Jan