From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3569 invoked by alias); 18 Feb 2014 17:38:38 -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 3555 invoked by uid 89); 18 Feb 2014 17:38:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_40,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f170.google.com Received: from mail-ve0-f170.google.com (HELO mail-ve0-f170.google.com) (209.85.128.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Feb 2014 17:38:35 +0000 Received: by mail-ve0-f170.google.com with SMTP id cz12so14125451veb.29 for ; Tue, 18 Feb 2014 09:38:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.94.77 with SMTP id da13mr2516713vdb.55.1392745112684; Tue, 18 Feb 2014 09:38:32 -0800 (PST) Received: by 10.220.13.2 with HTTP; Tue, 18 Feb 2014 09:38:32 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Feb 2014 17:38:00 -0000 Message-ID: Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Linus Torvalds To: Peter.Sewell@cl.cam.ac.uk Cc: "mark.batty@cl.cam.ac.uk" , Paul McKenney , Peter Zijlstra , Torvald Riegel , Will Deacon , Ramana Radhakrishnan , David Howells , "linux-arch@vger.kernel.org" , Linux Kernel Mailing List , Andrew Morton , Ingo Molnar , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-02/txt/msg00318.txt.bz2 On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell wrote: > > For example, suppose we have, in one compilation unit: > > void f(int ra, int*rb) { > if (ra==42) > *rb=42; > else > *rb=42; > } So this is a great example, and in general I really like your page at: > For more context, this example is taken from a summary of the thin-air > problem by Mark Batty and myself, > , and the problem with > dependencies via other compilation units was AFAIK first pointed out > by Hans Boehm. and the reason I like your page is that it really talks about the problem by pointing to the "unoptimized" code, and what hardware would do. As mentioned, I think that's actually the *correct* way to think about the problem space, because it allows the programmer to take hardware characteristics into account, without having to try to "describe" them at a source level. As to your example of if (ra) atomic_write(rb, A); else atomic_write(rb, B); I really think that it is ok to combine that into atomic_write(rb, ra ? A:B); (by virtue of "exact same behavior on actual hardware"), and then the only remaining question is whether the "ra?A:B" can be optimized to remove the conditional if A==B as in your example where both are "42". Agreed? Now, I would argue that the "naive" translation of that is unambiguous, and since "ra" is not volatile or magic in any way, then "ra?42:42" can obviously be optimized into just 42 - by the exact same rule that says "the compiler can do any transformation that is equivalent in the hardware". The compiler can *locally* decide that that is the right thing to do, and any programmer that complains about that decision is just crazy. So my "local machine behavior equivalency" rule means that that function can be optimized into a single "store 42 atomically into rb". Now, if it's *not* compiled locally, and is instead implemented as a macro (or inline function), there are obviously situations where "ra ? A : B" ends up having to do other things. In particular, X may be volatile or an atomic read that has ordering semantics, and then that expression doesn't become just "42", but that's a separate issue. It's not all that dissimilar to "function calls are sequence points", though, and obviously if the source of "ra" has semantic meaning, you have to honor that semantic meaning. Agreed? Linus