This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
> From: Stan Shebs <firstname.lastname@example.org>
> 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).
Do you have some data? Perhaps we can replace the division by simple lookup
> 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 :-)