From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Batty Subject: Re: [RFC][PATCH 0/5] arch: atomic rework Date: Tue, 18 Feb 2014 15:16:33 +0000 Message-ID: References: <20140218145645.GK4250@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-oa0-f45.google.com ([209.85.219.45]:50254 "EHLO mail-oa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755589AbaBRPQe (ORCPT ); Tue, 18 Feb 2014 10:16:34 -0500 In-Reply-To: <20140218145645.GK4250@linux.vnet.ibm.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "paulmck@linux.vnet.ibm.com" Cc: Peter Sewell , peterz@infradead.org, Torvald Riegel , torvalds@linux-foundation.org, Will Deacon , Ramana.Radhakrishnan@arm.com, dhowells@redhat.com, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, mingo@kernel.org, gcc@gcc.gnu.org Hi Paul, Thanks for the document. I'm looking forward to reading the bits about dependency chains in Linux. > One point of confusion for me... Example 4 says "language must allow". > Shouldn't that be "language is permitted to allow"? When we say "allow", we mean that the optimised execution should be allowed by the specification, and Implicitly, the unoptimised execution should remain allowed too. We want to be concrete about what the language specification allows, and that's why we say "must". It is not to disallow the unoptimised execution. > Seems like an > implementation is always within its rights to avoid an optimization if > its implementation prevents it from safely detecting the oppportunity > for that optimization. That's right. - Mark > Or am I missing something here? > > Thanx, Paul >