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 12:26:16 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Richard Guenther <richard.guenther@...il.com>
cc:	Matthew Wilcox <matthew@....cx>, Andi Kleen <andi@...stfloor.org>,
	Dirk Hohndel <hohndel@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	jim owens <jowens@...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>,
	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>, jh@...e.cz
Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y
 impact

On Fri, 9 Jan 2009, Richard Guenther wrote:
> 
> This is a case where the improved IPA-CP (interprocedural constant 
> propagation) of GCC 4.4 may help.  In general GCC cannot say how a call 
> argument may affect optimization if the function was inlined, so the 
> size estimates are done with just looking at the function body, not the 
> arguments (well, for GCC 4.4 this is not completely true, there is now 
> some "heuristics").  With IPA-CP GCC will clone the function for the 
> constant arguments, optimize it and eventually inline it if it is small 
> enough.  At the moment this happens only if all callers call the 
> function with the same constant though (at least I think so).

Ok, that's useless. The whole point is that everybody gives different - 
but still constant - arguments.

> The above is definitely one case where using a macro or forced inlining is
> a better idea than to trust a compiler to figure out that it can optimize the
> function to a size suitable for inlining if called with a constant parameter.

.. and forced inlining is what we default to. But that's when "let's try 
letting gcc optimize this" fails. And macros get really unreadable, really 
quickly.

> > Maybe there was something else going on, and maybe Ingo's tests were off,
> > but this is an example of gcc not inlining WHEN WE TOLD IT TO, and when
> > the function was a single instruction.
> >
> > How can anybody possibly not consider that to be "stupid"?
> 
> Because it's a hard problem, it's not stupid to fail here - you didn't tell the
> compiler the function optimizes!

Well, actually we did. It's that "inline" there. That's how things used to 
work. It's like "no". It means "no". It doesn't mean "yes, I really want 
to s*ck your d*ck, but I'm just screaming no at the top of my lungs 
because I think I should do so".

See?

And you do have to realize that Linux has been using gcc for a _loong_ 
while. You can talk all you want about how "inline" is just a hint, but 
the fact is, it didn't use to be. gcc people _made_ it so, and are having 
a damn hard time admitting that it's causing problems.

> Experience tells us that people do not know better.  Maybe the kernel is
> an exception here

Oh, I can well believe it. 

And I don't even think that kernel people get it right nearly enough, but 
since for the kernel it can even be a _correctness_ issue, at least if we 
get it wrong, everybody sees it.

When _some_ compiler versions get it wrong, it's a disaster.

> But would you still want small functions be inlined even if they are not
> marked inline?

If you can really tell that they are that small, yes. 

> They do - just constant arguments are obviously not used for optimizing
> before inlining.  Otherwise you'd scream bloody murder at us for all the
> increase in compile-time ;)

A large portion of that has gone away now that everybody uses ccache. And 
if you only did it for functions that we _mark_ inline, it wouldn't even 
be true. Because those are the ones that presumably really should be 
inlined.

So no, I don't believe you. You much too easily dismiss the fact that 
we've explicitly marked these functions for inlining, and then you say 
"but we were too stupid".

If you cannot afford to do the real job, then trust the user. Don't guess.

		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/