Re: [patch] h8300.md: Fix the failure of 20020904-1.c.

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Eric,

> > 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
> operand.

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
> simpler.

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

  (truncate:QI
    (udiv:HI
      (match_operand:HI 1 "register_operand" "0")
      (zero_extend:HI (match_operand:QI 2 "register_operand" "r"))))

Kazu Hirata