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

On Tue, Jul 14, 2026 at 7:40 PM Mark Wielaard <[email protected]> wrote:
>
> Hi H.J.
>
> On Tue, Jul 14, 2026 at 07:10:19PM +0800, H.J. Lu wrote:
> > On Tue, Jul 14, 2026 at 6:33 PM Mark Wielaard <[email protected]> wrote:
> > > On Mon, Jul 13, 2026 at 06:05:56PM +0800, H.J. Lu wrote:
> > > > -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.
> > >
> > > It looks like you need a clear definition of "safe" and "unsafe". And
> > > there are probably multiple different ones depending on context.
> > > e.g. you could provide an option that makes it "safe" for the user to
> > > rely on the instruction length. Or a guarantee that the code will
> > > always use the shortest encoding. Another for not trying to optimize
> > > away "redundent" encoding prefixes. Or removing "nop" sequences. Or
> > > one that explicitly changes any nop sequences to the most efficient
> > > one (for a particular length), etc.
> > >
> > > Just make sure you agree on what "safe" and "unsafe" mean for
> > > particular optimization levels/switches. And document them so the user
> > > knows what they can expect when enabling the "optimization".
> > >
> > By "safe", I mean an optimization won't break applications.   The
> > most x86 assembler optimizations are for shorter encodings.   They
> > shouldn't make an application stop working as expected.
>
> That is not a very good definition because it doesn't specify what
> kind of transformations are done. Every transformation might "break" a
> specific application or stop it they don't expect a particular
> "optimization". You have to be explicit about the kind of
> transformation that is done by a particular optimization so the user
> can expect them.

It is intentionally vague so that the assembler can implement all
kinds of optimizations.  The question is what to do when we
find out that an optimization breaks an application.  We should
evaluate it case by case.

> What you could do for example is limit optimizations to specific
> instruction sets. If I understand your original motivation it was to
> use more efficient/shorter sse encodings. Why not put those under a
> specific -Osse option for example? Then it is immediately clear why to
> use that particular optimization without mixing it with any others.
>


-- 
H.J.