2015-02-18 14:59 GMT+03:00 Georg-Johann Lay <a...@gjlay.de>: > Am 02/17/2015 um 03:34 PM schrieb Denis Chertykov: > >> 2015-02-17 14:12 GMT+03:00 Georg-Johann Lay <a...@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.