On Fri, 9 Jan 2009, Theodore Tso wrote: > I'm beginning to think that for the kernel, we should just simply > remove CONFIG_OPTIMIZE_INLINING (so that inline means > "always_inline"), and -fno-inline-functions > -fno-inline-functions-called-one (so that gcc never inlines functions > behind our back) --- and then we create tools that count how many times > functions get used, and how big functions are, so that we can flag if some > function really should be marked inline when it isn't or vice versa. > > But given that this is a very hard thing for an automated program > todo, let's write some tools so we can easily put a human in the loop, > who can add or remove inline keywords where it makes sense, and let's > give up on gcc being able to "guess" correctly. > > For some things, like register allocation, I can accept that the > compiler will usually get these things right. But whether or not to > inline a function seems to be one of those things that humans (perhaps > with some tools assist) can still do a better job than compilers.
Adding a function histogram in ftrace should be trivial. I can write one up if you want. It will only count the functions not inlined. -- Steve -- 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
