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.