From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E9A2C4743C for ; Fri, 4 Jun 2021 18:23:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 79438613E9 for ; Fri, 4 Jun 2021 18:23:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230037AbhFDSZo (ORCPT ); Fri, 4 Jun 2021 14:25:44 -0400 Received: from netrider.rowland.org ([192.131.102.5]:56895 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S229726AbhFDSZo (ORCPT ); Fri, 4 Jun 2021 14:25:44 -0400 Received: (qmail 1689062 invoked by uid 1000); 4 Jun 2021 14:23:57 -0400 Date: Fri, 4 Jun 2021 14:23:57 -0400 From: Alan Stern To: Linus Torvalds Cc: Peter Zijlstra , Will Deacon , "Paul E. McKenney" , Andrea Parri , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Linux Kernel Mailing List , linux-toolchains@vger.kernel.org, linux-arch Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: <20210604182357.GA1688170@rowland.harvard.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Jun 04, 2021 at 10:10:29AM -0700, Linus Torvalds wrote: > On Fri, Jun 4, 2021 at 9:37 AM Peter Zijlstra wrote: > > > > > > > > Why is "volatile_if()" not just > > > > > > #define barier_true() ({ barrier(); 1; }) > > > > > > #define volatile_if(x) if ((x) && barrier_true()) > > > > Because we weren't sure compilers weren't still allowed to optimize the > > branch away. > > This isn't about some "compiler folks think". > > The above CANNOT be compiled any other way than with a branch. > > A compiler that optimizes a branch away is simply broken. > > Of course, the actual condition (ie "x" above) has to be something > that the compiler cannot statically determine is a constant, but since > the whole - and only - point is that there will be a READ_ONCE() or > similar there, that's not an issue. In fact there is one weird case where it is an issue (mentioned in memory-barriers.txt): If some obscure arch-specific header file does: #define FOO 1 and an unwitting programmer writes: volatile_if (READ_ONCE(*y) % FOO == 0) WRITE_ONCE(*z, 5); then the compiler _can_ statically determine that the condition is a constant, in spite of the READ_ONCE, but this fact isn't apparent to the programmer. The generated object code will include both the read and the write, but there won't necessarily be any ordering between them. I don't know if cases like this exist in the kernel. It wouldn't be surprising if they did though, particularly in situations where a feature (like multi-level page tables) may be compiled away. Alan