[Bug target/103252] questionable codegen with kmovd

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.