This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] h8300.md: Enable divxu.b on H8/300
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 09 Sep 2002 10:25:52 -0600
- Subject: Re: [patch] h8300.md: Enable divxu.b on H8/300
- Reply-to: law at redhat dot com
In message <20020908.042053.27957454.kazu@cs.umass.edu>, Kazu Hirata writes:
>Hi,
>
>Attached is a patch to enable divxu.b on H8/300.
>
>It seems disabled for no reason.
Probably an oversight. Possibly due to the limited usefullness of
divxu.b
Looking at the udivmodXXX expanders, I have some concerns about how they
modify operand1, which is supposed to be a source operand. It seems to
me that can't be correct:
(define_expand "udivmodqi4"
[(set (match_operand:HI 1 "register_operand" "")
(and:HI (match_dup 1)
(const_int 255)))
(parallel [(set (match_operand:QI 0 "register_operand" "")
(truncate:QI
(udiv:HI
(match_dup 1)
(zero_extend:HI
(match_operand:QI 2 "register_operand" "")))))
(set (match_operand:QI 3 "register_operand" "")
(truncate:QI
(umod:HI
(match_dup 1)
(zero_extend:HI (match_dup 2)))))])]
Note how the first insn generated by this expander will mask off the
upper bits of operand 1, but we have no assurance that operand1 is not
live after this insn. It seems to me that we should have copied operand1
into a new temporary so that we can safely modify it.
Jeff