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 | <CAMe9rOqoQ+hyzmEp7wuqTfDD=K_Vx8DT9+4Vv4neUroJpBVFpQ@mail.gmail.com> |
On Wed, Jul 8, 2026 at 1:54 PM Jan Beulich <[email protected]> wrote: > > On 07.07.2026 23:18, H.J. Lu wrote: > > On Tue, Jul 7, 2026 at 10:35 PM Jan Beulich <[email protected]> wrote: > >> On 07.07.2026 16:21, Sam James wrote: > >>> Just what you keep saying? > >>> > >>> "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 > > > > I disagree. I added -O to assembler for > > > > On x86, some instructions have alternate shorter encodings: > > > > 1. When the upper 32 bits of destination registers of > > > > andq $imm31, %r64 > > testq $imm31, %r64 > > xorq %r64, %r64 > > subq %r64, %r64 > > > > known to be zero, we can encode them without the REX_W bit: > > > > andl $imm31, %r32 > > testl $imm31, %r32 > > xorl %r32, %r32 > > subl %r32, %r32 > > > > This optimization is enabled with -O, -O2 and -Os. > > 2. Since 0xb0 mov with 32-bit destination registers zero-extends 32-bit > > immediate to 64-bit destination register, we can use it to encode 64-bit > > mov with 32-bit immediates. This optimization is enabled with -O, -O2 > > and -Os. > > 3. Since the upper bits of destination registers of VEX128 and EVEX128 > > instructions are extended to zero, if all bits of destination registers > > of AVX256 or AVX512 instructions are zero, we can use VEX128 or EVEX128 > > encoding to encode AVX256 or AVX512 instructions. When 2 source > > registers are identical, AVX256 and AVX512 andn and xor instructions: > > > > VOP %reg, %reg, %dest_reg > > > > can be encoded with > > > > VOP128 %reg, %reg, %dest_reg > > > > This optimization is enabled with -O2 and -Os. > > 4. 16-bit, 32-bit and 64-bit register tests with immediate may be > > encoded as 8-bit register test with immediate. This optimization is > > enabled with -Os. > > > > These optimizations were intended for compiler generated assembly > > codes. > > Why would that be? I.e. why would the compiler emit sub-optimal code, > for the assembler to tidy after it? > Compilers may miss the optimal encoding. That is where assembler optimization comes in. -- H.J. _______________________________________________ Valgrind-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-developers