DragonFly BSD
DragonFly kernel List (threaded) for 2006-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: "Dmitri Nikulin" <dnikulin@xxxxxxxxx>
Date: Thu, 15 Jun 2006 23:15:35 +1000

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


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


-- Dmitri Nikulin

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]