Non-optimal code generated for H8

[Segher Boessenkool]

On Wed, Oct 30, 2019 at 01:59:26PM -0600, Jeff Law wrote:
> On 10/30/19 1:53 PM, Mikael Tillenius wrote:
> > The AVR example was interesting since it generates reasonable code.
> > 
> > After a few experiments I strongly believe that it is the call to
> > __mulhi3 that stops GCC from doing CSE on the pointer expressions. If I
> > add a fake mulhi3 insn CSE seems to do its work and just generates the
> > address calculation once. But of course the code will not work since the
> > instruction is not present in the hardware. I see at least three
> > possible solutions:
> > 
> > 1) Teach CSE to work even for calls to __mulhi3
> THe name shouldn't matter at all to CSE.  What's important to CSE is
> interpreting the REG_EQUAL note in this case and finding the bounds of
> the insn chain that computes the value in the REG_EQUAL note.

Yeah, and the call insns *are* properly marked as "const" as well, so I
don't see what is going on (and the CSE dump file is content-less).

> > (define_expand "umulhisi3"
> >   [(set (match_operand:SI 0 "register_operand" "")
> >         (mult:SI (zero_extend:SI (match_operand:HI 1 "register_operand" ""))
> >                  ;; intentionally-mismatched modes
> >                  (match_operand:HI 2 "reg_or_nibble_operand" "")))]
> >   "TARGET_H8300H || TARGET_H8300S"
> >   {
> >     if (GET_MODE (operands[2]) != VOIDmode)
> >       operands[2] = gen_rtx_ZERO_EXTEND (SImode, operands[2]);
> >   })
> 
> Note the HImode on operand 2.  That seems wrong.  Hopefully it wasn't
> something *I* did eons ago.  Anyway, that might be a place to start
> looking.  I wouldn't be surprised if all the work we've done in the last
> decade to tighten up our checking of predicates is somehow causing us to
> not use umulhisi3 in this context.

I get a __mulsi3 even, probably need more flags than just -ms :-)
(I used h8300-linux).


Segher