Re: [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms
"H.J. Lu" <[email protected]>
| Newsgroups | gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <CAMe9rOpjm+t6B=tCERDf5XK3Q9WQZufuXmbqYws==KbpbWU-+A@mail.gmail.com> |
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. > > > > I can see that there may be a desire to optimize asm()-generated code. > > That imo shouldn't be done by passing -Wa,-O... but rather by some > > other, to be invented machinery. (We could tie it to the #APP / #NO_APP > > markers that the compiler emits, for example.) > > > > Jan -- H.J. _______________________________________________ Valgrind-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-developers