Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756195AbZAIUhc (ORCPT ); Fri, 9 Jan 2009 15:37:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753399AbZAIUhU (ORCPT ); Fri, 9 Jan 2009 15:37:20 -0500 Received: from mail-bw0-f21.google.com ([209.85.218.21]:42042 "EHLO mail-bw0-f21.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752857AbZAIUhQ (ORCPT ); Fri, 9 Jan 2009 15:37:16 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KIX5gOtovExeHDeWI8YA7VQIT1HbloncRxCiI5SFhGl2nXWZzAskDVE6j8xGL1Zyr5 rtUIPm6wX6vE0CGk+soGl5yQeE/ipHKa2PmTwsdQUhnpAgRndfh7Ms9TQZDXm1If9z1B aVXF0zVZTAfdlYECWbz90MUbFzpPjBI8kCVuM= Message-ID: <84fc9c000901091237i68b2e495tab55e61fb3dbd565@mail.gmail.com> Date: Fri, 9 Jan 2009 21:37:13 +0100 From: "Richard Guenther" To: "Linus Torvalds" Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact Cc: "Matthew Wilcox" , "Andi Kleen" , "Dirk Hohndel" , "H. Peter Anvin" , "Ingo Molnar" , "jim owens" , "Chris Mason" , "Peter Zijlstra" , "Steven Rostedt" , paulmck@linux.vnet.ibm.com, "Gregory Haskins" , "Andrew Morton" , "Linux Kernel Mailing List" , linux-fsdevel , linux-btrfs , "Thomas Gleixner" , "Nick Piggin" , "Peter Morreale" , "Sven Dietrich" , jh@suse.cz In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <496648C7.5050700@zytor.com> <20090109172011.GD26290@one.firstfloor.org> <20090109172801.GC6936@parisc-linux.org> <20090109174719.GG26290@one.firstfloor.org> <20090109173914.GD6936@parisc-linux.org> <84fc9c000901091109t2c2aef2fu596f8807b0962688@mail.gmail.com> <84fc9c000901091214i16fc74b7q349433a5586d5619@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4834 Lines: 127 On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds wrote: > > > 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. Btw, both GCC 4.3 and upcoming GCC 4.4 inline the bit-test. This is what I used as a testcase (to avoid the single-call and single-constant cases): #define BITS_PER_LONG 32 static inline int constant_test_bit(int nr, const volatile unsigned long *addr) { return ((1UL << (nr % BITS_PER_LONG)) & (((unsigned long *)addr)[nr / BITS_PER_LONG])) != 0; } #define test_bit(nr, addr) \ (__builtin_constant_p((nr)) \ ? constant_test_bit((nr), (addr)) \ : variable_test_bit((nr), (addr))) int foo(unsigned long *addr) { return test_bit (5, addr); } int bar(unsigned long *addr) { return test_bit (6, addr); } at -Os even. >> 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. As it happens to work with your simple case it may still apply for more complex (thus appearantly big) cases. >> > 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? See below. > 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. We made it so 10 years ago. >> 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. Of course. If you use always_inline then it's even a compiler bug. >> 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. We're guessing way better than the average programmer. But if you are asking for a compiler option to disable guessing you can have it (you can already use #define inline always_inline and -fno-inline to get it). Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/