Too much. I rely on gcc (and other compilers) inlining functions that are
only placeholders for other calls to optimize generated code.
I need functions inlined if they're dead-ends, or call other functions
and return the foreign result without further calculation. I.e. they
don't need to save and restore registers because they're not using any.
That's about a 3-4 times speedup win for me (my compiler-compilers ..).
I produce lots of short functions from expression analysis. "a+b+c"
might generate 6 functions, one for each subexpression and one for each
referent.
If gcc can't detect the (tail-recursion at worst) case its dataflow
analysis is fundamentally broken. Given that it is broken, possibly
only for the assembler case (?? - isn't gcc using its
internal representation at this point?) it should at least be able to say
"i'm not sure" and fallback to saving/restoring registers.
> Note that this is not just a workaround for a bug. The fact is, that with
As phrased, it is! It looks more like one should just stop gcc being so
optimistic when it's data analysis doesn't warrant it.
> small-register-set, inlining functions is not likely to be all that big of
> a win (and is often a loss due to register allocation pressure) unless the
> function is _really_ small or for some special cases - and in both cases
> hopefully the function is marked inline already by the knowledgeable user.
The knowledgeable user relies on the knowledgable compiler here. All
studies show that hand-optimizing code is a waste of effort 99.99% of
the time, not least because it's unmaintainable. Experience says so
too. I've regretted every "optimization" I've ever done.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/