https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82260
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The insn has weird constraints:
[(set (match_operand:QI 0 "nonimmediate_operand"
"=q,q ,q ,r,r ,?r,m ,k,k,r,m,k")
(match_operand:QI 1 "general_operand"
"q ,qn,qm,q,rn,qm,qn,r,k,k,k,m"))]
I fail to see why qn or qm rather than just n or m in 2nd and 3rd alternative,
or qm rather than m in 6th alternative, because there are already earlier
alternatives with such constraint combinations.
>From pure instruction size POV, for the first 2 alternatives as can be seen say
on:
movb %al, %bl
movl %eax, %ebx
movb %cl, %dl
movl %ecx, %edx
movb %sil, %bl
movl %esi, %ebx
movb %bl, %sil
movl %ebx, %esi
movb %r12b, %al
movl %r12d, %eax
movb %r12b, %sil
movl %r12d, %esi
movb %al, %r14b
movl %eax, %r14d
movb $0x15, %al
movl $0x15, %eax
movb $-0x78, %bl
movl $-0x78, %ebx
it is clear that SI vs. QImode doesn't matter in most of the cases, at which
point we IMHO should use decisions we use when optimizing for speed.
The exceptions are the 2nd alternative above, which is always significantly
better to use QImode. And then the case where both operands in TARGET_64BIT
match R constraint but at least one does not match q constraint, where SImode
is shorter.
