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 | <CAMe9rOqXxuEevFD5PaHCrfwcLVM5O+UaaN6Vjvvc2gj-9vLOmw@mail.gmail.com> |
On Tue, Jul 14, 2026 at 6:33 PM Mark Wielaard <[email protected]> wrote: > > Hi, > > 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. -- H.J.