This is the mail archive of the
mailing list for the GCC project.
Re: [patch] h8300.md: Fix the failure of 20020904-1.c.
> > In udivmodqi4, the dividend is taken in HImode. Thus "(uchar)
> > 255" is taken as -1 in HImode.
> The patch that was applied to optabs.c aims at precisely fixing this
> problem: before, (uchar) 255 was sent unconverted as (const_int -1)
> to a HImode operand of udivqi3/udivmodqi4, thus resulting in 65535
> being effectively passed; now, (uchar) 255 is converted from
> (const_int -1) to (const_int 255) before being sent to a HImode
Hmm... Without my patch, the generated assembly code still contains
-1 in HImode.
> > The patch addresses this problem by splitting the udivmodqi4
> > pattern into an expander and an anonymous pattern. The expander
> > zeroes out the upper half of the dividend.
> Why do you need to do that ? The udivqi3 pattern of i386.md is much
Due to the above problem, I want to clear the upper half of the
dividend first. I could put both this clearing and actual div insn
within one assembly insn string, but that would be inefficient. This
is because the clearing part can often be combined with the insn that
sets the dividend. For example, in case of 20020904-1.c, there would
be a move insn that sets the dividend to -1. Anding this with 0xff
can be combined with the move insn. That is, we can simply load 255
as the dividend. This and is emitted by the expander.
Anyway, which patch is the patch to obtabs.c that you are refering to?
I would like to see why the code in optabs.c is not triggering.
By the way, is it OK to have HImode inside div:QI as in i386.md? The
h8 port is as ugly as
(match_operand:HI 1 "register_operand" "0")
(zero_extend:HI (match_operand:QI 2 "register_operand" "r"))))