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

On Mon, Jul 6, 2026 at 4:26 PM H.J. Lu <[email protected]> wrote:
>
> On Mon, Jul 6, 2026 at 3:22 PM Jan Beulich <[email protected]> wrote:
> >
> > On 06.07.2026 09:11, H.J. Lu wrote:
> > > On Mon, Jul 6, 2026 at 2:16 PM Jan Beulich <[email protected]> wrote:
> > >> On 03.07.2026 15:32, H.J. Lu wrote:
> > >>> On Fri, Jul 3, 2026 at 8:28 PM Jan Beulich <[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 <[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.
> > >
> > > 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.
>
> This should be done on a case by case basis.  For each issue like
> this, we should investigate and decide what to do.
>
> > Hence my earlier suggestion: Give them half a year to sort things by
> > reverting the change from the branch, once that was created.
> >
>
> VALGRIND_GET_NR_CONTEXT is defined in /usr/include/valgrind/valgrind.h.
> It will take a long time to get it changed in both valgrind source as
> well as all
> its users.   I don't think half a year is sufficient.
>

We should consider benefits vs drawbacks for this optimization.  Do we have
a list of applications which benefit from this optimization?


-- 
H.J.


_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers