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 7756AC47082 for ; Sun, 6 Jun 2021 01:29:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A42E613F7 for ; Sun, 6 Jun 2021 01:29:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230110AbhFFBay (ORCPT ); Sat, 5 Jun 2021 21:30:54 -0400 Received: from netrider.rowland.org ([192.131.102.5]:56167 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S230084AbhFFBaw (ORCPT ); Sat, 5 Jun 2021 21:30:52 -0400 Received: (qmail 1723601 invoked by uid 1000); 5 Jun 2021 21:29:03 -0400 Date: Sat, 5 Jun 2021 21:29:03 -0400 From: Alan Stern To: "Paul E. McKenney" Cc: Linus Torvalds , Peter Zijlstra , Will Deacon , 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: <20210606012903.GA1723421@rowland.harvard.edu> References: <20210604182708.GB1688170@rowland.harvard.edu> <20210604205600.GB4397@paulmck-ThinkPad-P17-Gen-1> <20210604214010.GD4397@paulmck-ThinkPad-P17-Gen-1> <20210605145739.GB1712909@rowland.harvard.edu> <20210606001418.GH4397@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210606001418.GH4397@paulmck-ThinkPad-P17-Gen-1> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 05, 2021 at 05:14:18PM -0700, Paul E. McKenney wrote: > On Sat, Jun 05, 2021 at 10:57:39AM -0400, Alan Stern wrote: > > Indeed, the expansion of the currently proposed version of > > > > volatile_if (A) { > > B; > > } else { > > C; > > } > > > > is basically the same as > > > > if (A) { > > barrier(); > > B; > > } else { > > barrier(); > > C; > > } > That does sound good, but... > > Current compilers beg to differ at -O2: https://godbolt.org/z/5K55Gardn > > ------------------------------------------------------------------------ > #define READ_ONCE(x) (*(volatile typeof(x) *)&(x)) > #define WRITE_ONCE(x, val) (READ_ONCE(x) = (val)) > #define barrier() __asm__ __volatile__("": : :"memory") > > int x, y; > > int main(int argc, char *argv[]) > { > if (READ_ONCE(x)) { > barrier(); > WRITE_ONCE(y, 1); > } else { > barrier(); > WRITE_ONCE(y, 1); > } > return 0; > } > ------------------------------------------------------------------------ > > Both gcc and clang generate a load followed by a store, with no branch. > ARM gets the same results from both compilers. > > As Linus suggested, removing one (but not both!) invocations of barrier() > does cause a branch to be emitted, so maybe that is a way forward. > Assuming it is more than just dumb luck, anyway. :-/ Interesting. And changing one of the branches from barrier() to __asm__ __volatile__("nop": : :"memory") also causes a branch to be emitted. So even though the compiler doesn't "look inside" assembly code, it does compare two pieces at least textually and apparently assumes if they are identical then they do the same thing. Alan