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

[Sam James]

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.

It makes clear what the intended usecase is. It could've been that for
example it was intended when using an old compiler but a new assembler,
I don't know.

>
> Jan

sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20260707/39880e5f/attachment-0001.sig>