On Thu, Sep 26, 2019 at 09:12:34AM -0600, Jeff Law wrote:
> On 9/26/19 12:49 AM, Jakub Jelinek wrote:
> > On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> >> (insn 13 12 14 2 (set (reg:SI 124)
> >> (const_int -939524096 [0xffffffffc8000000])) "j.c":10:54 161
> >> {*arm_movsi_insn}
> >> (nil))
> >>
> >> (insn 14 13 16 2 (parallel [
> >> (set (reg:SI 132)
> >> (plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
> >> (zero_extend:DI (reg:SI 124)))
> >> (reg:SI 130)))
> >
> > IMNSHO the bug is just in the backend, the above is not valid RTL.
> > SImode MULT has to have SImode operands, not DImode operands.
> Hmm, yea, I think you're right. I totally missed that last night.
>
> FWIW, we do allow the modes of the input operands to differ. But I
> don't think either is allowed to be wider than the result mode of the
> multiplication.
Sure, there are some rtl codes that can have different operands, but most of
them don't. The exceptions are shifts/rotates (the second operand can have
different mode, but result/first operand needs to be the same), comparisons
(result mode can be different from operand modes, but operand mode needs to
be the same), zero_extract/sign_extract, some vec_* etc.
Most binary arithmetic rtxes need to have the same mode for the result and
both arguments though.
> I think that means we punt this back to Wilco to fix since it's an ARM
> specific issue.
Sure.
Jakub
