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

[H.J. Lu]

On Mon, Jul 13, 2026 at 2:09 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 12.07.2026 17:37, Mark Wielaard wrote:
> > Hi Jan,
> >
> > On Tue, Jul 07, 2026 at 04:35:27PM +0200, Jan Beulich wrote:
> >> On 07.07.2026 16:21, Sam James wrote:
> >>> "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.
> >>
> >> I fear I wouldn't be happy with making such a statement in doc. For one,
> >> "intended" is weak enough that people may still think the options are
> >> worthwhile to use on compiler output. Plus there's the issue with inline
> >> assembly, which imo can plausibly be subject to optimization. Yet at
> >> this time we have no way to have optimization "kick in" only on those
> >> portions.
> >>
> >> I could perhaps live with a yet weaker version of what you suggest:
> >>
> >> "Assembler optimization is intended primarily for hand-written code.  If
> >>  you notice any effects on compiler generated code, please consider
> >>  raising a bug against the compiler.  Note, however, that this does not
> >>  extend to there possibly being effects on code originating from inline
> >>  assembly."
> >
> > I am not sure I understand why you want inline assembly excluded. Yes,
> > inline assembly is "hand-written", but only because there was no exact
> > way to make the compiler produce a specific sequence or encoding of
> > some instructions. How about something like:
> >
> > "Assembler optimization is intended primarily for hand-written
> > assembly files, not for use with compiler generated code (or inline
> > assembly crafted explicitly to produce a specific instruction sequence
> > or encoding).  If you notice any effects on compiler generated code,
> > please consider raising a bug against the compiler about a missed
> > optimization.  Note, however, that this does not extend to there
> > possibly being effects on code originating from hand-written assembly
> > code embedded as a whole into a higher-level language compiler."
>
> Well. You've seen H.J.'s reply, haven't you? His take is that -O very much
> is for compiler generated code. As just indicated on another thread, what
> is needed here first is an agreed upon understanding what we want to
> optimize (for). Intentions originally weren't made sufficiently clear, and
> hence views looks to have heavily diverged.
>

There are no hard criterias for assembler optimizations.   In general,
assembler can re-encode instructions for the same operation to save
space or improve performance.  We don't ask for performance improvements
in applications.  However, if we run into significant issues, like

https://sourceware.org/bugzilla/show_bug.cgi?id=34343

we ask for real applications to show performance improvements to
justify such drawbacks.

-- 
H.J.