This is the mail archive of the 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: Stan Shebs <>
   Date: Fri, 17 May 2002 09:25:32 -0700
   That's my personal suspicion too, but no, I don't have any real
   evidence.  The lack of hot spots in profiling is a strong hint.
   One oddball idea I've thought about is to functionize all the
   tree and rtl macros, and run a profile on that to see what are
   the most used/abused macros.
I know that the subreg-byte changes added a lot of overhead
particularly via the subreg_regno_offset() function (which was
an inline macro in my original diffs).

The divisions are what kill it.  That overhead could be eliminated
if all the mode sizes were powers of 2 and we had some
GET_MODE_SIZE_LOG2() interface.  Then we just transform all the
divides there into shifts.

   Then there's the extreme approach of having maintainers only
   accept patches that either remove code or make the compiler run
   faster... :-)

There is a better way, have maintainers work on approval of such
changes faster than approval of other changes :-)

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