This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
i386.md has overly restrictive constraints in mulsi3_1 and mulhi3_1
- To: gcc at gcc dot gnu dot org
- Subject: i386.md has overly restrictive constraints in mulsi3_1 and mulhi3_1
- From: Colin Howell <chowell at redhat dot com>
- Date: Mon, 23 Jul 2001 15:42:13 -0700 (PDT)
i386.md currently has the following patterns for 32-bit and 16-bit
signed multiplication:
(define_insn "*mulsi3_1"
[(set (match_operand:SI 0 "register_operand" "=r,r,r")
(mult:SI (match_operand:SI 1 "nonimmediate_operand" "%rm,0,0")
(match_operand:SI 2 "general_operand" "K,i,mr")))
(clobber (reg:CC 17))]
(define_insn "*mulhi3_1"
[(set (match_operand:HI 0 "register_operand" "=r,r,r")
(mult:HI (match_operand:HI 1 "nonimmediate_operand" "%rm,0,0")
(match_operand:HI 2 "general_operand" "K,i,mr")))
(clobber (reg:CC 17))]
I'm interested in alternative 1, which has constraints "r" "0" "i".
This implies that GCC will only allow an IMUL instruction to use a
large immediate value (larger than an 8-bit signed integer) for
operand 2 if operand 1 is also the destination register. This seems
unnecessarily restrictive. The actual IMUL instruction selected by
alternative 1 of these patterns allows any register or memory operand
for operand 1. Constraints of "r" "rm" "i" seem to make more sense.
I can't find any reason to impose this extra restriction on these
patterns. The same hardware instruction will be used if the
restriction is removed. There is no obvious sign of a performance
penalty for either the Pentium or Pentium Pro/II/III architectures in
Intel's documentation. Even if there might be a potential performance
loss in some cases (perhaps due to instruction length), wouldn't it be
better to describe this in the attributes rather than omitting the
instruction?
If there actually is a good reason for this restriction, could it at
least be documented in i386.md?