Re: C compile time

[Jan Hubicka <jh at suse dot cz>]

> 
> Maybe there should be an expand_function_called_once_inline() function 
> that does not duplicate the whole function body for inlining.  If you 
> already know that you're only going to inline that function and not 
> output it, then this should help a lot for memory consumption.  Of 
> course that doesn't help the backend...

Yes, it would be possible to avoid the duplication, but I am not sure
how much that will help - garbagecollecting the trees out does not seem
to take that much time even for insn-recog.c
> 
> With unit-at-a-time, do we start inlining from the callgraph leaves or 
> from the root?  If we do the former, than you could simply stop inining 

We still do the same inlining scheme as without unit-at-a-time (so from
the root).  I intended to change this once all frontends doing tree
inlining use unit-at-a-time.  It probably makes more sense to first
estimate sizes of reulting functions and decide what to inline precisely
and go away from current scheme of attributes deciding on inlining and
replace them by flags on cgraph edges.

> if a function grows too large.  Another thing you could try is to first 
> compute what the total size of all the functions would be after inlining 
> everything (all the information you need is available) and make inline 
> decisions based on that.
> 
> >Unfortunate thing on this path is that I will probably not be able to do
> >unit-at-a-time for C++ without some help and thus this work won't help
> >C++ where we get major problems.
> >
> 
> Yes -- you recently mentioned that Mark had some ideas about C++ 
> unit-at-a-time. Could you tell a bit more about that?

Mark does not like my current approach. C++ frontend currently contain
loop that does iterate over all known functions, virtual tables and
static data and outputs one only when it has been already assembled
reference to. (the templates instantiations and virtual tables are
created lazilly when needed)

I modified it to walk the function bodies to discover what static
initializers and templates are needed so I don't need to actually
assemble to see what is needed, but Mark would preffer approach that
expands everything available and then removes dead objects.

That means that I need to extend unit-at-a-time first to deal with data
structures as well (so one can cancel data structure from being output
when it is already expanded) and doing so also brings memory explission.
Mark thinks we should reduce memory overhead of the frontend first this
is bit more involved change that I feel I am able to do in C++ frontend
in 3.4 horizont.
> 
> >Other sollution would be to not give up so easilly and try to push more
> >on keeping compiler linear on the compilation.  For GCSE we probably can
> >give up when having too many memory references and simply do not record
> >the others.  Similarly we can deal with quadratic bottlenecks in the
> >scheduler, but I am not sure whether we will run into problems in
> >register allocation that is unavoidably quadratic by definition but do
> >far does not appear to cause major obstackles.
> >
> 
> Well if GCSE is O(N^3) then that is obviously a good place to start and 
> see what the effects are for the generated code.  But eventually, 
> keeping N small is the only thing that really helps if you have 

The N is actually number of memory references optimized via GCSE.  One
approach is to simply cut the references being optimized - we don't need
to GCSE all of them, so we can keep N small even with function bodies
being large.  Other aproach is, of course, region based optimization but
that is bit dificult...

Honza
> unavoidable quadratic or worse algorithms.  So that means, make sure 
> functions don't grow excessively large.  That helps reducing memory 
> consumption, too.
> 
> Gr.
> Steven
> 
>