[patch, avr] Fix ICE PR64452 pushing eliminated rtxes

Denis Chertykov chertykov@gmail.com
Wed Feb 18 12:45:00 GMT 2015


2015-02-18 14:59 GMT+03:00 Georg-Johann Lay <avr@gjlay.de>:
> Am 02/17/2015 um 03:34 PM schrieb Denis Chertykov:
>
>> 2015-02-17 14:12 GMT+03:00 Georg-Johann Lay <avr@gjlay.de>:
>>>
>>> Byte-wise pushing virtual regs like arg pointer migth result in patterns
>>> like
>>>
>>>   (set (mem:QI (post_dec:HI (reg:HI 32 SP)))
>>>        (subreg:QI (plus:HI (reg:HI 28)
>>>                            (const_int 17)) 0))
>>>
>>> after elimination.
>>>
>>> Attached patch uses new pushhi1_insn to push virtuals in HImode so that
>>> expressions like in subreg_reg from above can be reloaded.
>>>
>>> Ok to commit ?
>>>
>>> Johann
>>>
>>>          PR target/64452
>>>
>>>          * config/avr/avr.md (pushhi_insn): New insn.
>>>          (push<mode>1): Push virtual regs in one chunk using
>>> pushhi1_insn.
>>
>>
>> Approved.
>> (But I'm worry about this because it's reload related problem and it
>> can have a side effect)
>>
>> Denis.
>
>
> So you have a superior solution in mind?
>
> What side effects specifically?
>
> Currently the side effect is that reload gets simpler expressions and hence
> does not ICE.  There isn't even an insn that can push complex (plus rtx in
> this case) expressions or subregs thereof.  Even if there were such insns I
> don't think reload is supposed to handle them.
>
> The current implementation of push<mode>1 assumes that all RTXes which ever
> appear in a push can be decomposed into subregs and these can be simplified
> to some of the push insns, i.e. the push operand simplifies to REG or
> CONST0_RTX.  The subreg above, however, cannot be simplified to anything
> reload can handle and does not match an insn.  And supplying such an insn is
> pointless because that insn would need a scratch and hence require secondary
> reloads...
>
> plus rtxes are special as they might be produced by reload (R28 above is
> (hard_)frame_pointer).  For similar reason there are two addhi3 insns (one
> without scratch to accommodate reload and one generic with scratch for
> better performance.)

I don't have any concrete objections.
I'm worried because it's not so easy to predict all possible reloads.
(At least for me)

Denis.



More information about the Gcc-patches mailing list