Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2299285pxj; Sat, 5 Jun 2021 20:49:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytI8wG5x51fH8CCQvohWifRIDPxYGpgc5RUPLRW+yAX0UZquU/EUphv85tDcb+qfzq8GYD X-Received: by 2002:a50:d943:: with SMTP id u3mr12678443edj.175.1622951390559; Sat, 05 Jun 2021 20:49:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622951390; cv=none; d=google.com; s=arc-20160816; b=nb5sHLGVQvmJqHWB6ETDlfhnDfxtHaHWHTk8LR28AIXnNyukURdQMtwvuh54vczh11 1TzFzAr1WOD8CFnH+NhzCJqUHLpFGfJipGHRvMb0Igb3JFjg2SC4n8J7sOFHj1ZOPG6V dVbWifWB6BkpYdtsA+hG4BLohs3CzNowsGU0hUas7Kjg7pz3BMh0pp0EOdhv4KNCEj6e RzU8R4zt8HJ3bos+Rfn+Dxj+i2wDD4GA12hN36EqB+Y68kSSlMNthqIb8ceYa6GyH7Xc pDNz5xss9Eip+u6Rp2+kXW4O5bj43kMYxXfB2IJ+T/vj4SRi4CbCpuUZAVKp1SIOngNA JX8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=oYTZ0aVkCupy147WxRNKwW/8x7k8EKzPl0T5uXCBADE=; b=baEGMkmQ3RDSRI9y5Jj9otQFUtoEWwKzNcPZccWcAL3hHjgzxt4gUdA4F7bUEpYknB UFpSOhYVSyEr8n+UqDgq67IO9j8oehAs7F+KGU3M15cJ/ajEwdE5H8Hv0//CXOgWgMiv nU9GVptjmhTkNm1OTVSYoTAU/nDHQkLBf3EozjHcaw9WDgZj+zSI4LOHYVl+A957SWpW ncmAroidxxhj6Ga4uKa/SGQU+Ku3Q+XtLqEDG+9cyyhZEHJSR7mXIPjirknG0UYP9HTB e6ASaCYK8cZhutk5fcHq/L0GkerlXkUK9SK/V1AUty/DVRCw29JJ0O/7WuSPXKL/JxIf DVEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Zo6bRdKV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v27si8973554ejf.542.2021.06.05.20.49.26; Sat, 05 Jun 2021 20:49:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=Zo6bRdKV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230110AbhFFDu2 (ORCPT + 99 others); Sat, 5 Jun 2021 23:50:28 -0400 Received: from mail-lf1-f44.google.com ([209.85.167.44]:44937 "EHLO mail-lf1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbhFFDu1 (ORCPT ); Sat, 5 Jun 2021 23:50:27 -0400 Received: by mail-lf1-f44.google.com with SMTP id r198so17024334lff.11 for ; Sat, 05 Jun 2021 20:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oYTZ0aVkCupy147WxRNKwW/8x7k8EKzPl0T5uXCBADE=; b=Zo6bRdKVAXx4rABaNQFHDKIcnmCE0mQIEHI2xzzZsiSixlnzFQRE7LEfhxGkjl6YKa tqQ2emAPcylF8ergb0DoTwbkVnUyd3IZD1Fc/0M87b1M2fNep6H/kY+77J3vUZh3Ge3U tTIZehMKt1Lln/1Lh7r9w8XgIHb5V+QKF+nkE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oYTZ0aVkCupy147WxRNKwW/8x7k8EKzPl0T5uXCBADE=; b=Ypw9svuwuWGO1Owtg5ZWDCPvAKAsEbrdTicY30nALD1pqjt0JAmgRxa04R3e/9BgM2 E1f3sGWr6UV4I47eIF6gghukuixpCcU/UX19LQEsmq57kL9bdu2Z3Hk5qe9+NI9pgy6C 9BYu8zLm8te0Q59u0VcFC1yhybLwxiJmkDOwE9pY83pvRov0xedlK3LZlTxdFNSwlT1x dFCt4F4ngQm/yuinCx2i1ax1BZPtSzgqJKHAbr/GI5H+ohjbUEo7mrB8wBNcoNao5BCy kW51iHMkn6FMV+D3Ycz+bqjBfWSK7X0joAW0klQfixXq0mUP04CWuOeFjipxr1k7bNad koBQ== X-Gm-Message-State: AOAM532bmnVBc1ymNzXXK0s0LtjK2CUieKwRkjyytLeraWqJlv997N5t ibkrd16Kc3jC9eHa+Iu1Jn4Lio+ybMCo9Q5PXE4= X-Received: by 2002:a05:6512:3fa2:: with SMTP id x34mr7518555lfa.437.1622951243147; Sat, 05 Jun 2021 20:47:23 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id s11sm1245475ljc.66.2021.06.05.20.47.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 20:47:23 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id r5so20414382lfr.5 for ; Sat, 05 Jun 2021 20:47:22 -0700 (PDT) X-Received: by 2002:a05:6512:374b:: with SMTP id a11mr7389694lfs.377.1622950876683; Sat, 05 Jun 2021 20:41:16 -0700 (PDT) MIME-Version: 1.0 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> <20210606012903.GA1723421@rowland.harvard.edu> In-Reply-To: <20210606012903.GA1723421@rowland.harvard.edu> From: Linus Torvalds Date: Sat, 5 Jun 2021 20:41:00 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: Alan Stern , Segher Boessenkool Cc: "Paul E. McKenney" , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 5, 2021 at 6:29 PM Alan Stern wrote: > > 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. That's actually a feature in some cases, ie the ability to do CSE on asm statements (ie the "always has the same output" optimization that the docs talk about). So gcc has always looked at the asm string for that reason, afaik. I think it's something of a bug when it comes to "asm volatile", but the documentation isn't exactly super-specific. There is a statement of "Under certain circumstances, GCC may duplicate (or remove duplicates of) your assembly code when optimizing" and a suggestion of using "%=" to generate a unique instance of an asm. Which might actually be a good idea for "barrier()", just in case. However, the problem with that is that I don't think we are guaranteed to have a universal comment character for asm statements. IOW, it might be a good idea to do something like #define barrier() \ __asm__ __volatile__("# barrier %=": : :"memory") but I'm not 100% convinced that '#' is always a comment in asm code, so the above might not actually build everywhere. However, *testing* the above (in my config, where '#' does work as a comment character) shows that gcc doesn't actually consider them to be distinct EVEN THEN, and will still merge two barrier statements. That's distressing. So the gcc docs are actively wrong, and %= does nothing - it will still compare as the exact same inline asm, because the string equality testing is apparently done before any expansion. Something like this *does* seem to work: #define ____barrier(id) __asm__ __volatile__("#" #id: : :"memory") #define __barrier(id) ____barrier(id) #define barrier() __barrier(__COUNTER__) which is "interesting" or "disgusting" depending on how you happen to feel. And again - the above works only as long as "#" is a valid comment character in the assembler. And I have this very dim memory of us having comments in inline asm, and it breaking certain configurations (for when the assembler that the compiler uses is a special human-unfriendly one that only accepts compiler output). You could make even more disgusting hacks, and have it generate something like .pushsection .discard.barrier .long #id .popsection instead of a comment. We already expect that to work and have generic inline asm cases that generate code like that. Linus