Re: C compile time

[Jan Hubicka <jh at suse dot cz>]

> > It would be nice if some of the inlining issues got sorted out for 3.4,
> > and -Winline became deterministic again.
> 
> -Winline has never been deterministic.  It just seemed that way.
> 
> Since 3.0 , it's just been broken.  It just didn't warn you about a lot
> of the cases where it didn't inline.
> 
> Before that, it was still non-deterministic, in the sense that the RTL
> inliner had throttles that would keep it from inlining as much as you
> might have liked.
> 
> So, the problem has gotten worse, but it's not a new problem.
> 
> For 3.4, we could consider going back to the "bottom-up" inlining
> strategy.  That might be better than what we have now, even though it's
> inherently quadratic.  Implementing bottom-up inlining wouldn't be
> terribly hard; all the same tree-inlining machinery would work.
> 
> One of the things we seem to forget in all the inlining discussion is
> that inlining has never worked well.  In fact, one of the big
> motivations in going to function-at-a-time was to try to fix all the
> lameness in the RTL inliner!  On many large C++ programs, the 2.95 era
> compilers would simply exhaust all memory trying to do inlining...
> 
> I'm pretty convinced that there's no easy fix, unfortunately.

With cgraph code, I am considering relatively simple heuristics taking
extra arguments of maximal growth of the compilation unit, maximal
growth of big function and bif functio threshold.

I think we can simply order cgraph rev postorder (so start decision from
leaves of the callgraph "tree") and decide to inline each small function
(or function called once) while copmuting infromation about the growth
of destination function body and overall growth.
The thresholds should prevent us from running into degerate cases (that
are generally either that we construct extravagantly large function
bodies by deep inlining or inlining too many times or we enlarge whole
program too much).  Perhaps the maximal growth of the compilation unit
is redundant.

Then we can perform top-down inlining once we made bottom-up decisions.

I tend to believe that this should fix problems we are seeing (modulo
the determinism mentioned here, tsk :) This is currently my main
motivation to get cgraph code used :)

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
>