From: Georg-Johann Lay <avr@gjlay.de>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [named address] ice-on-valid: in postreload.c:reload_cse_simplify_operands
Date: Wed, 10 Aug 2011 14:04:00 -0000 [thread overview]
Message-ID: <4E428F89.1060104@gjlay.de> (raw)
In-Reply-To: <201108091716.p79HG1qV028050@d06av02.portsmouth.uk.ibm.com>
Ulrich Weigand wrote:
> Georg-Johann Lay wrote:
>
>> Thanks, it works.
>
> OK, thanks for testing!
>
>> std Y+2,r31 ; 30 *movphi/3 [length = 7]
>> std Y+1,r30
>
> I'm actually not seeing those (maybe I'm using a different code
> base than you were using ...)
>
> But I still see that the frame is created. The problem is that IRA
> thinks it needs to allocate a pseudo on the stack, and creates a
> stack slot for it. But then reload goes and just reloads the
> pseudo into a hard register anyway, and simply doesn't need the
> stack slot ... but it was already allocated and accounted for
> such that get_frame_size () no longer returns 0.
The stack slot is an IRA hog because there are plenty of hard regs.
>> I frequently see IRA doing a very bad job for small register classes
>> like here. Maybe it's better to take it completely away from IRA
>> and write the load as
>>
>> (set (reg:HI)
>> (unspec:HI (post_inc:PHI (reg:PHI Z))))
>>
>> Loading from __pgm is actually an unspec, i.e. reading two times from
>> the same address will yield the same result.
>
> This really seems to be a problem in IRA somewhere, but I'd guess it
> would be better to fix in there instead of working around it. Maybe
> you should open a bug an get in touch with the IRA maintainers ...
It surely is an IRA issue. However, it's extremely unlikely that anyone
cares for SSA/RTL optimization flaws that just show up on AVR or are
reported against AVR. And if a patch turns out to overcharge IRA
like, e.g. in
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02655.html
the patch won't be integrated.
Moreover, this one is hard to reproduce because it needs you patch,
my patch and is for a "irrelevant" target.
Johann
> Bye,
> Ulrich
next prev parent reply other threads:[~2011-08-10 14:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 13:43 Georg-Johann Lay
2011-08-04 16:20 ` Ulrich Weigand
2011-08-04 16:26 ` DJ Delorie
2011-08-04 16:33 ` Ulrich Weigand
2011-08-04 17:28 ` Georg-Johann Lay
2011-08-05 10:19 ` Ulrich Weigand
2011-08-05 12:47 ` Georg-Johann Lay
2011-08-05 13:24 ` Ulrich Weigand
2011-08-05 14:09 ` Michael Matz
2011-08-05 14:29 ` Ulrich Weigand
2011-08-05 20:43 ` Ulrich Weigand
2011-08-05 20:47 ` DJ Delorie
2011-08-05 21:01 ` Ulrich Weigand
2011-08-05 21:08 ` DJ Delorie
2011-08-08 11:38 ` Georg-Johann Lay
2011-08-09 17:16 ` Ulrich Weigand
2011-08-10 14:04 ` Georg-Johann Lay [this message]
2011-08-17 17:44 ` Georg-Johann Lay
2011-08-18 14:38 ` Ulrich Weigand
2011-08-21 16:43 ` Georg-Johann Lay
2011-08-22 12:39 ` Ulrich Weigand
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=4E428F89.1060104@gjlay.de \
--to=avr@gjlay.de \
--cc=gcc@gcc.gnu.org \
--cc=uweigand@de.ibm.com \
/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).