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

[H.J. Lu]

On Mon, Jul 13, 2026 at 6:00 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.07.2026 11:55, H.J. Lu wrote:
> > 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.
>
> This kind of a model doesn't work, for me at least. If I spend time on
> implementing an optimization, I don't want to see the work dropped on the
> floor just because some random piece of code has optimization enabled

No one can guarantee that his/her codes won't cause any issues.   But
one should be prepared to deal with it.

> when it shouldn't have (prior to the code subject to optimization actually
> having been audited to be safe against the effects in all possible ways).

-On/-Os I added to assembler which should be 100% safe.  If you can't
or won't make it 100% safe, you can add another option to perform unsafe
optimization.


-- 
H.J.