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

[Jan Beulich]

On 06.07.2026 09:11, H.J. Lu wrote:
> On Mon, Jul 6, 2026 at 2:16 PM Jan Beulich <jbeulich@suse.com> wrote:
>> 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.
> 
> When we are informed that an assembler optimization breaks the
> application, we should consider disabling such optimization.

While on the surface this may look like a pragmatic approach, it really
doesn't scale: One could then artificially construct uses in applications,
just for the (really: all) optimizations to then be disabled.

Hence my earlier suggestion: Give them half a year to sort things by
reverting the change from the branch, once that was created.

Jan