From: Denis Chertykov <chertykov@gmail.com>
To: Georg-Johann Lay <avr@gjlay.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, avr] Fix ICE PR64452 pushing eliminated rtxes
Date: Wed, 18 Feb 2015 12:45:00 -0000 [thread overview]
Message-ID: <CADOs=zYyaF1wVsPD9r35iPLX24rU2oTWtoN+FpOK13WMtQTmwg@mail.gmail.com> (raw)
In-Reply-To: <54E47EB3.1@gjlay.de>
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.
prev parent reply other threads:[~2015-02-18 12:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 11:13 Georg-Johann Lay
2015-02-17 14:34 ` Denis Chertykov
2015-02-18 11:59 ` Georg-Johann Lay
2015-02-18 12:45 ` Denis Chertykov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADOs=zYyaF1wVsPD9r35iPLX24rU2oTWtoN+FpOK13WMtQTmwg@mail.gmail.com' \
--to=chertykov@gmail.com \
--cc=avr@gjlay.de \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).