This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc compile-time performance


   From: dewar@gnat.com (Robert Dewar)
   Date: Sat, 18 May 2002 10:37:05 -0400 (EDT)

   The point here is that if you want a fast compiler, GCC is *so* far from
   meeting this criterion, that I don't think you will get very far in fixing
   it. You can put in a huge effort, and perhaps make it twice as fast, but
   that's less than a year's gain in hardware speed, and the rate of gain is
   the same in schools and third world countries, even if they are using older
   obsolete hardware.

This is probably the most depressing posting I've seen on this
list in a long time.

Let me prove you wrong by showing you a %13 improvement in -O2
compilation speed I was able to achieve in about 5 minutes of work
Friday afternoon.  It was a silly piece of code in the CSE
infrastructure, taking up the bulk of CSE's overhead.

This kind of stuff is all over and I bet one could double the
performance of GCC in a couple of days if one really cared to do so.

In fact, I found this bug so quickly (and it has been with us for
SO LONG, since February 2001 at the very least) that I really doubt
anyone has had any serious looks at profiles of GCC building something
interesting with -O2.

I think it is very sexy to work on the performance of the compiler
itself.  I used to be blown away when I had an opportunity to use
the MIPS compilers during my internship at SGI.  They were
instantaneous even with the equivalent of -O2 enabled.  That was
hot stuff and I dearly miss having compilation times like this.

I vow to bring that kind of compilation speed back to GCC,
irrespective of negative depressing comments like those of yours.

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	Fri May 17 17:21:38 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,30 @@
      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 (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 = &REG_VALUES (i);
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]