On Fri, 9 Jan 2009, Ingo Molnar wrote: > > Core kernel developers tend to be quite inline-conscious and generally do > not believe that making something inline will make it go faster. Some of us core kernel developers tend to believe that: - inlining is supposed to work like macros, and should make the compiler do decisions BASED ON CALL-SITE. This is one of the most _common_ reasons for inlining. Making the compiler select static code rather than dynamic code, and using inlining as a nice macro. We can pass in a flag with a constant value, and only the case that matters will be compiled. It's not about size - or necessarily even performance - at all. It's about abstraction, and a way of writing code. And the thing is, as long as gcc does what we ask, we can notice when _we_ did something wrong. We can say "ok, we should just remove the inline" etc. But when gcc then essentially flips a coin, and inlines things we don't want to, it dilutes the whole value of inlining - because now gcc does things that actually does hurt us. We get oopses that have a nice symbolic back-trace, and it reports an error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined things to the point that only an expert can realize "oh, the bug was actually five hundred lines up, in that other function that was just called once, so gcc inlined it even though it is huge". See? THIS is the problem with gcc heuristics. It's not about quality of code, it's about RELIABILITY of code. The reason people use C for system programming is because the language is a reasonably portable way to get the expected end results WITHOUT the compiler making a lot of semantic changes behind your back. Inlining is also the wrong thing to do _even_ if it makes code smaller and faster if you inline the unlikely case, or inlining causes more live variables that cause stack pressure. And we KNOW this happens. Again, I'd be much happier if we had a compiler option to just does "do what I _say_, dammit", and then we can fix up the mistakes. Because then they are _our_ mistakes, not some random compiler version that throws a dice! Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
