|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y
|| ||Fri, 9 Jan 2009 08:28:14 -0800 (PST)|
|| ||jim owens <jowens-AT-hp.com>, "H. Peter Anvin" <hpa-AT-zytor.com>,
Chris Mason <chris.mason-AT-oracle.com>,
Peter Zijlstra <peterz-AT-infradead.org>,
Steven Rostedt <rostedt-AT-goodmis.org>,
paulmck-AT-linux.vnet.ibm.com, Gregory Haskins <ghaskins-AT-novell.com>,
Matthew Wilcox <matthew-AT-wil.cx>,
Andi Kleen <andi-AT-firstfloor.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>,
Thomas Gleixner <tglx-AT-linutronix.de>,
Nick Piggin <npiggin-AT-suse.de>,
Peter Morreale <pmorreale-AT-novell.com>,
Sven Dietrich <SDietrich-AT-novell.com>|
|| ||Article, Thread
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!
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)