Re: gcc compile-time performance

[Alexandre Oliva <aoliva at redhat dot com>]

On May 17, 2002, "Chip Cuntz" <chip.cuntz@earthling.net> wrote:

>> It's also interesting to note how the compiler tree keeps taking
>> longer to compile.

> On the dog of an AIX box I have it takes two days to bootstrap gcc!

Well, mine takes about the whole week to bootstrap and test it.


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'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.

Perhaps switching to CONST_INTs with modes would alleviate both of the
problems: we could then use no-wider-than-necessary underlying types
for CONST_INTs, alleviating the use of 64-bit wide HOST_WIDE_INTs, and
remove a number of checks for sign-extension of CONST_INTs, since
they'd no longer be necessary.

These would be a significant amount of work, and it's not clear that
using the mode of a CONST_INT to determine which integer type to use
to hold it would be a win in general.

Anyway, food for thought.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer