Re: [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms
Jan Beulich via Valgrind-developers <valgrind-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
| Newsgroups | gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
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 <[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.) Jan _______________________________________________ Valgrind-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-developers