From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16001 invoked by alias); 18 Feb 2014 05:02:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15988 invoked by uid 89); 18 Feb 2014 05:02:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e35.co.us.ibm.com Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 18 Feb 2014 05:01:59 +0000 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 17 Feb 2014 22:01:57 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 17 Feb 2014 22:01:54 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id EEF2219D8036 for ; Mon, 17 Feb 2014 22:01:52 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp08026.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1I51URi4653496 for ; Tue, 18 Feb 2014 06:01:30 +0100 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id s1I55I05026340 for ; Mon, 17 Feb 2014 22:05:18 -0700 Received: from paulmck-ThinkPad-W500 (dyn9050023097.mts.ibm.com [9.50.23.97] (may be forged)) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id s1I55GMM026311; Mon, 17 Feb 2014 22:05:17 -0700 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id 40196387BAE; Mon, 17 Feb 2014 21:01:52 -0800 (PST) Date: Tue, 18 Feb 2014 05:02:00 -0000 From: "Paul E. McKenney" To: Linus Torvalds Cc: Torvald Riegel , Will Deacon , Peter Zijlstra , Ramana Radhakrishnan , David Howells , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "mingo@kernel.org" , "gcc@gcc.gnu.org" Subject: Re: [RFC][PATCH 0/5] arch: atomic rework Message-ID: <20140218050152.GF4250@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1392352981.18779.3800.camel@triegel.csb> <20140214172920.GQ4250@linux.vnet.ibm.com> <1392486310.18779.6447.camel@triegel.csb> <1392666947.18779.6838.camel@triegel.csb> <20140218030002.GA15857@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14021805-6688-0000-0000-000006B12D6D X-SW-Source: 2014-02/txt/msg00291.txt.bz2 On Mon, Feb 17, 2014 at 07:24:56PM -0800, Linus Torvalds wrote: > On Mon, Feb 17, 2014 at 7:00 PM, Paul E. McKenney > wrote: > > > > One example that I learned about last week uses the branch-prediction > > hardware to validate value speculation. And no, I am not at all a fan > > of value speculation, in case you were curious. > > Heh. See the example I used in my reply to Alec Teal. It basically > broke the same dependency the same way. ;-) > Yes, value speculation of reads is simply wrong, the same way > speculative writes are simply wrong. The dependency chain matters, and > is meaningful, and breaking it is actively bad. > > As far as I can tell, the intent is that you can't do value > speculation (except perhaps for the "relaxed", which quite frankly > sounds largely useless). But then I do get very very nervous when > people talk about "proving" certain values. That was certainly my intent, but as you might have notice in the discussion earlier in this thread, the intent can get lost pretty quickly. ;-) The HPC guys appear to be the most interested in breaking dependencies. Their software does't rely on dependencies, and from their viewpoint anything that has any chance of leaving an FP unit of any type idle is a very bad thing. But there are probably other benchmarks for which breaking dependencies gives a few percent performance boost. Thanx, Paul