Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755654AbaBTRfB (ORCPT ); Thu, 20 Feb 2014 12:35:01 -0500 Received: from mail-vc0-f170.google.com ([209.85.220.170]:37841 "EHLO mail-vc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322AbaBTRe6 (ORCPT ); Thu, 20 Feb 2014 12:34:58 -0500 MIME-Version: 1.0 In-Reply-To: <1392916492.18779.10136.camel@triegel.csb> References: <1392321837.18779.3249.camel@triegel.csb> <20140214020144.GO4250@linux.vnet.ibm.com> <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> <1392740258.18779.7732.camel@triegel.csb> <1392752867.18779.8120.camel@triegel.csb> <1392916492.18779.10136.camel@triegel.csb> Date: Thu, 20 Feb 2014 09:34:57 -0800 X-Google-Sender-Auth: 6SNDSLXxR_-y1Dul7UmmhgtxYxk Message-ID: Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Linus Torvalds To: Torvald Riegel Cc: Paul McKenney , 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" , Mark Batty , Peter Sewell Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote: >> >> So the clarification is basically to the statement that the "if >> (consume(p)) a" version *would* have an ordering guarantee between the >> read of "p" and "a", but the "consume(p) ? a : b" would *not* have >> such an ordering guarantee. Yes? > > Not as I understand it. If my reply above wasn't clear, let me know and > I'll try to rephrase it into something that is. Yeah, so you and Paul agree. And as I mentioned in the email that crossed with yours, I think that means that the standard is overly complex, hard to understand, fragile, and all *pointlessly* so. Btw, there are many ways that "use a consume as an input to a conditional" can happen. In particular, even if the result is actually *used* like a pointer as far as the programmer is concerned, tricks like pointer compression etc can well mean that the "pointer" is actually at least partly implemented using conditionals, so that some paths end up being only dependent through a comparison of the pointer value. So I very much did *not* want to complicate the "litmus test" code snippet when Paul tried to make it more complex, but I do think that there are cases where code that "looks" like pure pointer chasing actually is not for some cases, and then can become basically that litmus test for some path. Just to give you an example: in simple list handling it is not at all unusual to have a special node that is discovered by comparing the address, not by just loading from the pointer and following the list itself. Examples of that would be a HEAD node in a doubly linked list (Linux uses this concept quite widely, it's our default list implementation), or it could be a place-marker ("cursor" entry) in the list for safe traversal in the presence of concurrent deletes etc. And obviously there is the already much earlier mentioned compiler-induced compare, due to value speculation, that can basically create such sequences even wherethey did not originally exist in the source code itself. So even if you work with "pointer dereferences", and thus match that particular consume pattern, I really don't see why anybody would think that "hey, we can ignore any control dependencies" is a good idea. It's a *TERRIBLE* idea. And as mentioned, it's a terrible idea with no upsides. It doesn't help compiler optimizations for the case it's *intended* to help, since those optimizations can still be done without the horribly broken semantics. It doesn't help compiler writers, it just confuses them. And it sure as hell doesn't help users. 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/