https://sourceware.org/bugzilla/show_bug.cgi?id=34343
--- Comment #5 from Sourceware Commits <cvs-commit at gcc dot gnu.org> --- The binutils-2_47-branch branch has been updated by H.J. Lu <[email protected]>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=acd18f5244167f458f5e23252c4a7b050157389a commit acd18f5244167f458f5e23252c4a7b050157389a Author: H.J. Lu <[email protected]> Date: Sun Jul 12 18:24:42 2026 +0800 x86: Disable XCHG to MOV optimization The -O option was added to x86 assembler by commit b6f8c7c45229a8a5405079e586bfbaad396d2cbe Author: H.J. Lu <[email protected]> Date: Tue Feb 27 07:36:33 2018 -0800 x86: Add -O[2|s] assembler command-line options 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. The optimization changes may take a long time to be put into GCC. The similar SSE move encoding optimization for GCC was first proposed in Feb, 2019: https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516941.html It finally went in Mar, 2020: commit 5358e8f5800daa0012fc9d06705d64bbb21fa07b Author: H.J. Lu <[email protected]> Date: Thu Mar 5 16:45:05 2020 -0800 i386: Properly encode vector registers in vector move Such optimizations are useful for compiler generated codes since they work with released versions of GCC which don't have such optimized encoding. We assume that it is safe to use on compiler generated codes. When we are informed that an assembler optimization introduces a significant drawback, we will investigate its drawbacks and benefits. If its drawbacks outweigh its benefits, such optimization should be removed. commit 1c3c3e4b3c2ac2eed9abcbce0b9cba1be10ed3f0 Author: Jan Beulich <[email protected]> Date: Fri Jun 19 09:47:21 2026 +0200 x86: optimize XCHG to MOV for same-register forms breaks valgrind: https://bugs.kde.org/show_bug.cgi?id=522533 "xchgl %ecx,%ecx" in VALGRIND_GET_NR_CONTEXT, which is defined in /usr/include/valgrind/valgrind.h: #define VALGRIND_GET_NR_CONTEXT(_zzq_rlval) \ { volatile OrigFn* _zzq_orig = &(_zzq_rlval); \ volatile unsigned int __addr; \ __asm__ volatile(__SPECIAL_INSTRUCTION_PREAMBLE \ /* %EAX = guest_NRADDR */ \ "xchgl %%ecx,%%ecx" \ : "=a" (__addr) \ : \ : "cc", "memory" \ ); \ _zzq_orig->nraddr = __addr; \ } has special meanings and shouldn't be changed by assembler even when assembler optimization is enabled. Since there are no any evidences to show its benefits, we can't say that it is useful at all. This patch disables this optimization, which may be enabled with a different option. gas/ PR gas/34343 * config/tc-i386.c (optimize_for_disabled_optimizations): New. (optimize_encoding): Optimize "xchg %rN, %rN" to "mov %rN, %rN" only if optimize_for_disabled_optimizations isn't 0. * testsuite/gas/i386/optimize-2b.d: Updated. * testsuite/gas/i386/x86-64-optimize-3b.d: Likewise. Signed-off-by: H.J. Lu <[email protected]> (cherry picked from commit 49652cd8ecbb4c305a9a0e9099016edb138e6953) -- You are receiving this mail because: You are on the CC list for the bug.
