This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

i386.md has overly restrictive constraints in mulsi3_1 and mulhi3_1


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]