Re: C compile time

[Mark Mitchell <mark@codesourcery.com>]

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

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