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

[Jan Beulich]

On 07.07.2026 16:21, Sam James wrote:
> Jan Beulich <jbeulich@suse.com> writes:
> 
>> On 06.07.2026 10:22, Sam James wrote:
>>> Jan Beulich <jbeulich@suse.com> writes:
>>>
>>>> On 03.07.2026 15:32, H.J. Lu wrote:
>>>>> On Fri, Jul 3, 2026 at 8:28 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 03.07.2026 13:39, H.J. Lu wrote:
>>>>>>> On Fri, Jul 3, 2026 at 6:04 PM Sam James <sam@gentoo.org> wrote:
>>>>>>>>
>>>>>>>> Jan Beulich <jbeulich@suse.com> writes:
>>>>>>>>
>>>>>>>>> On 03.07.2026 08:09, Paul Floyd wrote:
>>>>>>>>>> On 2026-07-03 08:00, Jan Beulich wrote:
>>>>>>>>>>> On 03.07.2026 06:55, Paul Floyd wrote:
>>>>>>>>>>>> Would it be possible for gas to only do this transformation if the source and destination registers are different?
>>>>>>>>>>> When the registers are different, this transformation is invalid to do.
>>>>>>>>>>
>>>>>>>>>> OK so you are optimising a no-op. Does GCC use it as a no-op?
>>>>>>>>>
>>>>>>>>> I don't expect so. In fact, my take is that -O... should not be used on
>>>>>>>>> compiler generated code. The compiler should do whatever optimizations
>>>>>>>>> are possible / sensible, and it should not emit code which can (easily)
>>>>>>>>> further be optimized. (Easily because the assembler really only does
>>>>>>>>> very simple and pretty obvious transformations.)
>>>>>>>>
>>>>>>>> Yes, that's reasonable. We should document it though.
>>>>>>>
>>>>>>> -O should be safe for compiler generated codes.
>>>>>>
>>>>>> The question isn't about "being safe". -O should be safe on whatever input.
>>>>>> If it's not, it's a bug.
>>>>>>
>>>>>> The question is whether it is plausible to use -O... at all for compiler
>>>>>> generated code. I causes extra overhead in the assembler, after all. If the
>>>>>> compiler did a decent job, all of that extra overhead is going to be in
>>>>>> vein. (As said elsewhere, the situation is different for code coming from
>>>>>> asm() - that's not really compiler generated code.)
>>>>>>
>>>>>
>>>>> From what we have learned so far, "XCHG REG,REG" has been done
>>>>> on purpose and compilers never generate them automatically.   Assembler
>>>>> should leave them alone even with encoding optimization.
>>>>
>>>> No, why? Optimization is specifically for hand-coded assembly, so what a
>>>> compiler emits doesn't matter here. Following this argumentation of yours,
>>>> we should remove all optimization again from gas. People can use any
>>>> particular encoding "on purpose", after all. As said elsewhere, if you're
>>>> after particular encodings, don't engage optimization in the first place.
>>>
>>> Let's please document that though.
>>
>> I'm having a hard time seeing what exactly you want documented. Likely not
>> "optimization can change what you've written", as that entirely obvious. So
>> please could you propose something that fits your desires?
> 
> Just what you keep saying?
> 
> "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."

Jan