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

Jan Beulich <jbeulich-IBi9RG/[email protected]> writes:

> On 03.07.2026 15:32, H.J. Lu wrote:
>> On Fri, Jul 3, 2026 at 8:28 PM Jan Beulich <jbeulich-IBi9RG/[email protected]> wrote:
>>>
>>> On 03.07.2026 13:39, H.J. Lu wrote:
>>>> On Fri, Jul 3, 2026 at 6:04 PM Sam James <[email protected]> wrote:
>>>>>
>>>>> Jan Beulich <jbeulich-IBi9RG/[email protected]> 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.

>
> Jan

_______________________________________________
Valgrind-developers mailing list
Valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/valgrind-developers

-----BEGIN PGP SIGNATURE-----

iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmpLZdobFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx
QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkDYX
APsHKuxxlDuTItC5g0KonegDjYFuHrRrk4K7R0PEI+CLIQD/c3NQBRdEbuTcR62I
LRyannOubg3R8GenEyJl3wWQ5wU=
=anjN
-----END PGP SIGNATURE-----