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