linux-kernel - Re: [patch] measurements, numbers about CONFIG_OPTIMIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Jan 2009 08:28:14 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	jim owens <jowens@...com>, "H. Peter Anvin" <hpa@...or.com>,
	Chris Mason <chris.mason@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	paulmck@...ux.vnet.ibm.com, Gregory Haskins <ghaskins@...ell.com>,
	Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y
 impact

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/