Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756656AbZALUKa (ORCPT ); Mon, 12 Jan 2009 15:10:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754669AbZALUKS (ORCPT ); Mon, 12 Jan 2009 15:10:18 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:50094 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753498AbZALUKP (ORCPT ); Mon, 12 Jan 2009 15:10:15 -0500 Date: Mon, 12 Jan 2009 12:08:47 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Andi Kleen cc: Bernd Schmidt , 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: <20090111201427.GP26290@one.firstfloor.org> <1231704939.25018.548.camel@macbook.infradead.org> <20090111203441.GQ26290@one.firstfloor.org> <20090112001255.GR26290@one.firstfloor.org> <20090112005228.GS26290@one.firstfloor.org> <496B86B5.3090707@t-online.de> <20090112193201.GA23848@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: 1868 Lines: 41 On Mon, 12 Jan 2009, Linus Torvalds wrote: > > Type-based aliasing is unacceptably stupid to begin with, and gcc took > that stupidity to totally new heights by making it actually more important > than even statically visible aliasing. Btw, there are good forms of type-based aliasing. The 'restrict' keyword actually makes sense as a way to say "this pointer points to data that you cannot reach any other way". Of course, almost nobody uses it, and quite frankly, inlining can destroy that one too (a pointer that is restricted in the callEE is not necessarily restricted at all in the callER, and an inliner that doesn't track that subtle distinction will be very unhappy). So compiler people usually don't much like 'restrict' - because it i very limited (you might even say restricted) in its meaning, and doesn't allow for nearly the same kind of wild optimizations than the insane standard C type-aliasing allows. The best option, of course, is for a compiler to handle just _static_ alias information that it can prove (whether by use of 'restrict' or by actually doing some fancy real analysis of its own allocations), and letting the hardware do run-time dynamic alias analysis. I suspect gcc people were a bit stressed out by Itanium support - it's an insane architecture that basically requires an insane compiler for reasonable performance, and I think the Itanium people ended up brain-washing a lot of people who might otherwise have been sane. So maybe I should blame Intel. Or HP. Because they almost certainly were at least a _part_ reason for bad compiler decisions. 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/