Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754710AbZAKXHe (ORCPT ); Sun, 11 Jan 2009 18:07:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751858AbZAKXHM (ORCPT ); Sun, 11 Jan 2009 18:07:12 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:56569 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbZAKXHJ (ORCPT ); Sun, 11 Jan 2009 18:07:09 -0500 Date: Sun, 11 Jan 2009 15:05:53 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Andi Kleen cc: David Woodhouse , Andrew Morton , Ingo Molnar , Harvey Harrison , "H. Peter Anvin" , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , jh@suse.cz Subject: Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning In-Reply-To: Message-ID: References: <20090109231227.GA25070@elte.hu> <20090110010125.GA31031@elte.hu> <20090109174158.096dee70.akpm@linux-foundation.org> <20090110030216.GW26290@one.firstfloor.org> <1231676801.25018.150.camel@macbook.infradead.org> <20090111181307.GM26290@one.firstfloor.org> <20090111201427.GP26290@one.firstfloor.org> <1231704939.25018.548.camel@macbook.infradead.org> <20090111203441.GQ26290@one.firstfloor.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2384 Lines: 77 On Sun, 11 Jan 2009, Linus Torvalds wrote: > On Sun, 11 Jan 2009, Andi Kleen wrote: > > > > Was -- i think that got fixed in gcc. But again only in newer versions. > > I doubt it. People have said that about a million times, it has never > gotten fixed, and I've never seen any actual proof. In fact, I just double-checked. Try this: struct a { unsigned long array[200]; int a; }; struct b { int b; unsigned long array[200]; }; extern int fn3(int, void *); extern int fn4(int, void *); static inline __attribute__((always_inline)) int fn1(int flag) { struct a a; return fn3(flag, &a); } static inline __attribute__((always_inline)) int fn2(int flag) { struct b b; return fn4(flag, &b); } int fn(int flag) { if (flag & 1) return fn1(flag); return fn2(flag); } (yeah, I made sure it would inline with "always_inline" just so that the issue wouldn't be hidden by any "avoid stack frames" flags). Gcc creates a big stack frame that contains _both_ 'a' and 'b', and does not merge the allocations together even though they clearly have no overlap in usage. Both 'a' and 'b' get 201 long-words (1608 bytes) of stack, causing the inlined version to have 3kB+ of stack, even though the non-inlined one would never use more than half of it. So please stop claiming this is fixed. It's not fixed, never has been, and quite frankly, probably never will be because the lifetime analysis is hard enough (ie once you inline and there is any complex usage, CSE etc will quite possibly mix up the lifetimes - the above is clearly not any _realistic_ example). So even if the above trivial case could be fixed, I suspect a more complex real-life case would still keep the allocations separate. Because merging the allocations and re-using the same stack for both really is pretty non-trivial, and the best solution is to simply not inline. (And yeah, the above is such an extreme case that gcc seems to realize that it makes no sense to inline because the stack frame is _so_ big. I don't know what the default stack frame limit is, but it's apparently smaller than 1.5kB ;) Linus -- 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/