warning about 'large-function-growth limit reached'

[Dmitri Nikulin]

On 6/15/06, joerg at xxxxxxxxxxxxxxxxx <joerg at 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