Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756804AbZALUFY (ORCPT ); Mon, 12 Jan 2009 15:05:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752578AbZALUFH (ORCPT ); Mon, 12 Jan 2009 15:05:07 -0500 Received: from mailout10.t-online.de ([194.25.134.21]:43042 "EHLO mailout10.t-online.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918AbZALUFF (ORCPT ); Mon, 12 Jan 2009 15:05:05 -0500 Message-ID: <496BA036.3010101@t-online.de> Date: Mon, 12 Jan 2009 20:55:34 +0100 From: Bernd Schmidt User-Agent: Thunderbird 2.0.0.19 (X11/20090102) MIME-Version: 1.0 To: Linus Torvalds CC: Andi Kleen , 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 References: <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> <20090112001255.GR26290@one.firstfloor.org> <20090112005228.GS26290@one.firstfloor.org> <496B86B5.3090707@t-online.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: ZkddcqZSghvT-2k5KDKPEjGbT23avGJfLVAC26Hw3mIKQLol6W7TGNm0SZ9Ou4xZGX X-TOI-MSGID: f7146ea3-30ce-4a15-a23e-82144b43667c Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2081 Lines: 59 Linus Torvalds wrote: > > On Mon, 12 Jan 2009, Bernd Schmidt wrote: >> Something at the back of my mind said "aliasing". >> >> $ gcc linus.c -O2 -S ; grep subl linus.s >> subl $1624, %esp >> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s >> subl $824, %esp >> >> That's with 4.3.2. > > Interesting. > > Nonsensical, but interesting. > > Since they have no overlap in lifetime, confusing this with aliasing is > really really broken (if the functions _hadn't_ been inlined, you'd have > gotten the same address for the two variables anyway! So anybody who > thinks that they need different addresses because they are different types > is really really fundmantally confused!). I've never really looked at the stack slot sharing code. But I think it's not hard to see what's going on: "no overlap in lifetime" may be a temporary state. Let's say you have { variable_of_some_type a; writes to a; other stuff; reads from a; } { variable_of_some_other_type b; writes to b; other stuff; reads from b; } At the point where the compiler generates RTL, stack space has to be allocated for variables A and B. At this point the lifetimes are non-overlapping. However, if the compiler chooses to put them into the same stack location, the RTL-based alias analysis will happily conclude (based on the differing types) that the reads from A and the writes to B can't possibly conflict, and some passes may end up reordering them. End result: overlapping lifetimes and overlapping stack slots. Oops. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -- 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/