Re: warning about 'large-function-growth limit reached'

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On 6/15/06, joerg@xxxxxxxxxxxxxxxxx <joerg@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jun 14, 2006 at 12:28:38PM -0700, Chuck Tuffli wrote:
> > These warnings appear in the build of the 1.4.x branch. I'm guessing
> > they aren't serious problems, but was currious what they are really
> > trying to say. The gcc doc only says 'Specifies maximal growth of
> > large function caused by inlining in percents'. Does this mean that
> > the inlined function exceeds some specified line count?
>
> Not line count but some arbitrary complexity measurement. Think of nodes
> in the AST. Some code parts want to inline functions with several pages
> of source...
>
> Joerg

Either way the limit itself is pretty arbitrary. gcc makes no
complaints about functions being extremely large, but it does seem to
care if *inlining* makes them extremely large. I suppose it wants to
enforce a limit to keep its optimizations from exposing their
naturally bad scalability (not necessarily a fault of the algorithms,
mind you). Either way inlining is overrated unless the function is
both extremely small and frequently used, and yet still too messy to
make a macro. With the way any useful processor will handle pipelining
and caching, the cost of a function call is very close to free anyway.

Inlining is still not as dangerous as loop unrolling. Imagine
unrolling a three-page loop with a thousand iterations. That's three
thousand pages of separate instructions, for what? I hope gcc handles
*that* correctly and notices the loop unroll is completely worthless,
in fact having to load that much more code into cache probably means
it's a pessimisation. Or compromises and encapsulates the body...

</tangent>

 -- Dmitri Nikulin