On Sat, 2009-01-10 at 04:02 +0100, Andi Kleen wrote:
> Long term that problem will hopefully disappear, as gcc learns to do cross
> source file inlining (like a lot of other compilers already do)
We've already been able to get GCC doing this for the kernel, in fact
(the --combine -fwhole-program stuff I was working on a while back).
It gives an interesting size reduction, especially in file systems and
other places where we tend to have functions with a single call site...
but in a different file.
Linus argues that we don't want that kind of inlining because it harms
debuggability, but that isn't _always_ true. Sometimes you weren't going
to get a backtrace if something goes wrong _anyway_. And even if the
size reduction doesn't necessarily give a corresponding performance
improvement, we might not care. In the embedded world, size does matter
too. And the numbers are such that you can happily keep debuginfo for
the shipped kernel builds and postprocess any backtraces you get. Just
as we can for distros.
In general, I would much prefer being able to trust the compiler, rather
than disabling its heuristics completely. We might not be able to trust
it right now, but we should be working towards that state. Not just
declaring that we know best, even though _sometimes_ we do.
I think we should:
- Unconditionally have 'inline' meaning 'always_inline'. If we say it,
we should mean it.
- Resist the temptation to use -fno-inline-functions. Allow GCC to
inline other things if it wants to.
- Reduce the number of unnecessary 'inline' markers, and have a policy
that the use of 'inline' should be accompanied by either a GCC PR#
or an explanation of why we couldn't reasonably have expected GCC to
get this particular case right.
- Have a similar policy of PR# or explanation for 'uninline' too.
I don't think we should just give up on GCC ever getting it right. That
way lies madness. As we've often found in the past.
--
David Woodhouse Open Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
