https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- On https://gcc.godbolt.org/z/KG63ErzEr I don't see anything wrong, ia32 has just a few GPRs and all of them are heavily used in the loop, so if the %k? registers aren't slower than memory, it seems just fine to me. For https://gcc.godbolt.org/z/15hnsb6of trunk emits kmovd %ecx, %k0 movl __libc_tsd_CTYPE_B@gotntpoff(%ebx), %ecx kmovd %k0, %eax movl %gs:(%ecx), %ecx testb $32, 1(%ecx,%eax,2) where it is unclear to me why if RA made the unfortunate decision here to use %k0 doesn't e.g. postreload fix that up, it has: (insn 221 94 95 17 (set (reg:SI 68 k0 [orig:130 c ] [130]) (reg:SI 2 cx [orig:130 c ] [130])) "pr103252.c":81:68 77 {*movsi_internal} (nil)) ... a few insns that don't touch %eax nor %k0 (insn 222 98 197 17 (set (reg:SI 0 ax [orig:130 c ] [130]) (reg:SI 68 k0 [orig:130 c ] [130])) "pr103252.c":81:43 77 {*movsi_internal} (nil)) so why does it the unnecessary hop through another register when it could have movl %ecx, %eax instead of the first kmovd and nothing instead of the second. Those 2 are the only %k0 uses.
