On 9/26/19 9:22 AM, Jakub Jelinek wrote:
> 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.
Right. My point is that the multiplication patterns are an exception as
well.
I don't like the exceptions for the multiplication patterns as I think
the same effect could have been achieved with more zero/sign extractions.
Jeff
