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 <CAMe9rOrN3QCQs=Ck8nHL1ZMyKane0YDomX-focAu=KkTCE2VPA@mail.gmail.com>
On Mon, Jul 13, 2026 at 5:56 PM Jan Beulich <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.