This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc compile-time performance
From: law@redhat.com
Date: Sun, 19 May 2002 11:11:08 -0600
The change to cselib causes my PAs to hang in cselib_invalidate_regno.
Can you find out why? That makes zero sense.
The only loop I added must terminate because eventually "next widest
mode" will hit VOIDmode and terminate the loop.
Maybe you used an older version of my patch that omitted the
VOIDmode check? I attach the current version below.
Does the PA backend's HARD_REGNO_MODE_OK return true for VOIDmode?
That's a bug if so.
2002-05-17 David S. Miller <davem@redhat.com>
* cselib.c (cselib_invalidate_regno): Only walk over the
registers we actually need to look at.
--- cselib.c.~1~ Mon Feb 18 18:53:22 2002
+++ cselib.c Sat May 18 22:04:00 2002
@@ -947,6 +947,7 @@
{
unsigned int endregno;
unsigned int i;
+ enum machine_mode tmpmode, nxtmode;
/* If we see pseudos after reload, something is _wrong_. */
if (reload_completed && regno >= FIRST_PSEUDO_REGISTER
@@ -958,10 +959,31 @@
into account, and we must also invalidate lower register numbers
if they contain values that overlap REGNO. */
endregno = regno + 1;
- if (regno < FIRST_PSEUDO_REGISTER && mode != VOIDmode)
- endregno = regno + HARD_REGNO_NREGS (regno, mode);
+ if (regno < FIRST_PSEUDO_REGISTER && mode != VOIDmode)
+ {
+ endregno = regno + HARD_REGNO_NREGS (regno, mode);
- for (i = 0; i < endregno; i++)
+ tmpmode = reg_raw_mode[regno];
+ nxtmode = GET_MODE_WIDER_MODE (tmpmode);
+ while (nxtmode != VOIDmode
+ && HARD_REGNO_MODE_OK (regno, nxtmode))
+ {
+ tmpmode = nxtmode;
+ nxtmode = GET_MODE_WIDER_MODE (tmpmode);
+ }
+
+ i = HARD_REGNO_NREGS (regno, tmpmode);
+ if (regno < i)
+ i = 0;
+ else
+ i = regno - i;
+ }
+ else
+ {
+ i = regno;
+ }
+
+ for (; i < endregno; i++)
{
struct elt_list **l = ®_VALUES (i);