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

[H.J. Lu]

On Mon, Jul 13, 2026 at 5:56 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.07.2026 11:28, Mark Wielaard wrote:
> > Hi Jan,
> >
> > On Mon, Jul 13, 2026 at 08:09:23AM +0200, Jan Beulich wrote:
> >> On 12.07.2026 17:37, Mark Wielaard wrote:
> >>> 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.
> >
> > OK, but lets document that then so people don't accidentially use -O
> > without knowing that the option doesn't have clear semantics. How
> > about simply:
> >
> > "Assembler optimization is currently an experimental feature that
> > might result in changing instruction encoding, replacement of
> > instructions by equivalent ones or removal of instructions that could
> > be seen as nops. Don't use it when you have code that depends on the
> > exact assembler instruction encodings."
>
> I could live with this (yet I'd still like to understand what the criteria
> would be to drop this experimental status). H.J. - I fear you may not like
> it in this shape?
>

No, I don't like it.


-- 
H.J.