Re: [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms
Mark Wielaard <[email protected]>
| Newsgroups | gmane.comp.debugging.valgrind.devel,gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
Hi Jan, On Tue, Jul 07, 2026 at 04:35:27PM +0200, Jan Beulich wrote: > On 07.07.2026 16:21, Sam James wrote: > > "Assembler optimization is intended for hand-written code, not to be > > used on compiler output." which then gives us licence to dispose with > > bugs reports like this, as opposed to the ambiguity right now. > > I fear I wouldn't be happy with making such a statement in doc. For one, > "intended" is weak enough that people may still think the options are > worthwhile to use on compiler output. Plus there's the issue with inline > assembly, which imo can plausibly be subject to optimization. Yet at > this time we have no way to have optimization "kick in" only on those > portions. > > I could perhaps live with a yet weaker version of what you suggest: > > "Assembler optimization is intended primarily for hand-written code. If > you notice any effects on compiler generated code, please consider > raising a bug against the compiler. Note, however, that this does not > extend to there possibly being effects on code originating from inline > assembly." 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." Cheers, Mark