public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <bernds@codesourcery.com>
To: Jeff Law <law@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Patch 2/9: Split up and reorganize some functions
Date: Fri, 18 Jun 2010 19:07:00 -0000	[thread overview]
Message-ID: <4C1BAC07.2020708@codesourcery.com> (raw)
In-Reply-To: <4C1BA845.3040207@redhat.com>

On 06/18/10 17:09, Jeff Law wrote:

> I think I'd give port maintainers a quick chance to chime in as to
> whether or not their port has registers in a class where the number of
> hard regs to represent a given mode varies within the class.   Otherwise
> it looks fine.

The reason why I think it's more correct this way is that we're going to
allocate the allocno from within its cover_class.  In these functions
we're trying to estimate how many registers are going to be used by an
allocno, and we should use the nregs we compute for that cover class,
even when adjusting the pressure for its superclasses (since none of the
extra registers in the superclasses can be used anyway).

Example: we have a class A of 64 bit registers and a 64 bit allocno with
cover class A; nregs would be 1.  The register pressure in A would be
increased by 1, and the pressure in ALL_REGS should also be increased
only by 1, even if ALL_REGS also contains 32 bit registers, since the
existence of those is irrelevant to the allocno we're looking at.  The
current code would recompute nregs when cl == ALL_REGS and set it to 2,
which I think is wrong.

> If you wanted to get the bulk of these changes in and old off on the
> behaviour change, then that'd be fine by me.

I'll just wait until we have consensus on that; if we decide it's not
correct I can then figure out how to adjust it (it would make it harder
to share code between the allocno/hard reg cases).

Thanks for the quick reviews.


Bernd

  reply	other threads:[~2010-06-18 17:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18 14:08 Patch 0/9: IRA cleanups and preparations for tracking subwords of DImode Bernd Schmidt
2010-06-18 14:08 ` Patch 1/9: Remove dead code Bernd Schmidt
2010-06-18 14:11   ` Jeff Law
2010-06-18 14:09 ` Patch 2/9: Split up and reorganize some functions Bernd Schmidt
2010-06-18 18:26   ` Jeff Law
2010-06-18 19:07     ` Bernd Schmidt [this message]
2010-06-21 16:08       ` Jeff Law
2010-06-21 16:21         ` Bernd Schmidt
2010-06-18 14:10 ` Patch 3/9: create some more small helper functions Bernd Schmidt
2010-06-18 22:07   ` Jeff Law
2010-06-18 14:11 ` Patch 4/9: minor formatting fix Bernd Schmidt
2010-06-18 14:19   ` Jeff Law
2010-06-18 14:12 ` Patch 5/9: rename allocno_set to minmax_set Bernd Schmidt
2010-06-18 14:42   ` Jeff Law
2010-06-18 14:25 ` Patch 6/9: remove "allocno" from live_range_t Bernd Schmidt
2010-06-18 18:16   ` Jeff Law
2010-06-25  2:22     ` Bernd Schmidt
2010-06-25  3:16       ` Jeff Law
2010-06-18 14:37 ` Patch 7/9: Introduce ira_object_t Bernd Schmidt
2010-06-18 22:07   ` Jeff Law
2010-06-18 14:48 ` Patch 8/9: track live ranges for objects Bernd Schmidt
2010-06-18 22:41   ` Jeff Law
2010-06-18 15:26 ` Patch 9/9: change FOR_EACH_ALLOCNO_CONFLICT to use objects Bernd Schmidt
2010-06-22  1:45   ` Jeff Law
2010-06-18 20:02 ` Patch 0/9: IRA cleanups and preparations for tracking subwords of DImode Vladimir N. Makarov
2010-06-18 20:11   ` Jeff Law
2010-06-21 18:01 ` Patch 10/9: track subwords of DImode allocnos Bernd Schmidt
2010-07-06 23:49   ` Ping: " Bernd Schmidt
2010-07-13 20:43   ` Jeff Law
2010-07-13 21:10     ` Bernd Schmidt
2010-07-13 22:01       ` Vladimir Makarov
2010-07-14  2:00         ` Bernd Schmidt
2010-07-22 18:00           ` Nathan Froyd
2010-07-22 18:25             ` Bernd Schmidt
2010-07-22 18:50               ` Nathan Froyd
2010-07-22 22:35                 ` Bernd Schmidt
2010-07-25  1:23                   ` H.J. Lu
2011-01-27  8:39                     ` H.J. Lu
2010-07-20 14:28         ` Bernd Schmidt
2010-07-20 14:44           ` Vladimir Makarov
2010-07-22 15:49             ` Bernd Schmidt
2010-07-14 19:06       ` Jeff Law

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=4C1BAC07.2020708@codesourcery.com \
    --to=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.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).