warning about 'large-function-growth limit reached'

[joerg at britannica.bec.de]

On Thu, Jun 15, 2006 at 11:15:35PM +1000, Dmitri Nikulin wrote:
> 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

Sure, because *forcing* it to inline large functions is the trigger for
the warning.

> 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 has other advantages, since it can allow e.g. constant
propagation.

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

Even loop unrolling is a difficult question. Consider code which has a
lot of special case for the loop variable modulo 16. Even if the loop
itself is 10 pages long, constant expression elimination can reduce it
to 10 pages for 16 iteration over all. It strongly depends on the code.

Joerg