Re: gcc compile-time performance

[Jan Hubicka <jh at suse dot cz>]

> I wonder how much of a performance win we'd observe by replacing every
> occurrence of:
> 
>   if (some_condition)
>     abort ();
> 
> with
> 
>   if (flag_internal_checks && some_condition)
>     abort ();

I would vote for using asserts around the compiler, but it has been disucssed
already. It can be interesting to try to define abort to empty statement so
most of the conditionals will get elliminated. Of course assuming that
trunc_int_for_mode will be properly constified.
> 
> 
> I've certainly contributed myself to slow downs in the compiler, by
> introducing sanity checks in a number of functions called quite often.
> 
> Other reasons for compiler slow down are the use of 64-bit
> HOST_WIDE_INTs where 32-bit ones could do pretty well (perhaps
> using multiple-precision integers for the cases where we currently
> need the 64-bit HOST_WIDE_INTs; not sure whether this wouldn't hurt
> performance further, though).
> 
> The trend of properly enforcing proper sign-extension of CONST_INTs
> for their modes has introduced not only a number of calls of
> trunc_int_for_mode to ensure sign extension, but also a number of such
> calls in sanity checks.

This is one of special cases, where we are redesigining compiler and currently
we are in the half of way, having the worse from both worlds.  THats why I am
quite optimistics about possibilities to improve perofmrance in future, once we
finish the current changes.  I believe 3.1 is about the first compiler, where
the huge changes that took the part in last three years gave some possitive
effect, I would expect more of it in fugure releases to be gained now relativly
cheaply.

For instance the Zdenek's bb renumbering patch has large performance impact for
testcases involving huge functions (including our attrtabs, recogs), just by
moving forward the cleanup of CFG datastructures we were woring on for quite a
some time.

Recently the frontends apepars to be much more expensive than they did in the
past, I would guess the current state of function-at-time combined with
statement-at-time for old frontends is similar case.

Similary we still have RTL inliner that does contain quite a lot of bookeeping
code around the code gneration. I am not sure how costy it is, but deleting
it once will be definite win...

Needless to say that if we suceed to make our globals effective, we can burn
away the CSE passes taking about 20% of optimized builds, but we are still
far away of that and no one appears to be walking that direction.

I guess we did mistake to thread performance time quite easilly, but from
a part is is unavoidable to do deeper changes to GCC design.

Honza