Re: gcc compile-time performance

[Jan Hubicka <jh at suse dot cz>]

>    From: Stan Shebs <shebs@apple.com>
>    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
table...

Honza
> 
> 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 :-)