Tree inlining for the C front end (part 3 of 3)

[Alexandre Oliva]

On Sep 25, 2001, Alexandre Oliva <aoliva@redhat.com> wrote:

> In any case, I'll get some bootstrap time numbers for those
> interested.

The results below are for a full bootstrap -j6, with all languages
enabled, on an Athlon 1.4GHz with 768 MB of SDRAM at 133MHz running
what originally was Red Hat Linux 7.2beta, with a number of updates
packages.

With patch #3 (the one that actually enables tree inlining in C):

real    41m54.863s
user    36m54.310s
sys     4m5.800s


Without it:

real    40m46.628s
user    35m49.400s
sys     4m5.520s

An increase of almost 3%, unfortunately.  Is this too much for a
start?  I believe some additional tweaking of the tree inlining
parameters would help, and that there already are people working on
that.

In any case, this work was never expected to improve performance or
compile-time by itself.  At this stage, inlining trees is no different
from inlining RTL.  But it's a step towards the direction of enabling
other optimizations on trees, optimizations that will only apply to
inlined functions if they're inlined as trees.  And that's where we're
likely to have a significant win.  The infrastructure for that is
already being worked on in the tree-ssa branch.  Perhaps patch #3
should only be applied to the branch?

In any case, I'd like very much to have patches #1 and #2, that move
the tree inlining infrastructure to a more language-independent
location, still be installed in mainline, to avoid divergence and ease
merging from the branch.  This would have a minor impact in C++
compile times, due to the introduction of hooks, but I hope that's not
asking too much.

-- 
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    *Please* write to mailing lists, not to me