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
