Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2743093pxj; Sun, 6 Jun 2021 12:25:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzA+a7jZGwXAn1OpiwckbQ2K4EZTA0j6WR/Li6om/rPJMNoZ7tChTOOm6DIdYTGEQvxb1Xb X-Received: by 2002:a05:6402:201:: with SMTP id t1mr16335235edv.149.1623007534073; Sun, 06 Jun 2021 12:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623007534; cv=none; d=google.com; s=arc-20160816; b=PzGGqhPoTzHCT4goeGA8tNHPxA8MuJbNc5Yv+HITrkWCUvkYb9PhSqC8MHVltfNn4/ NqivEiR2RYdtDjvmUjlEWK/KVblVGwy0iYEs4d+4RWYJpoz/XVJ6UAaQT+m92arLR79J k971HQwY2duFrEIpuv5TXSW1r/hRfuwotVJgDocpD457gaNitrRvBCtmeawW2rspfyFR nc004rVBYGP+j+w74EHSsPab3rDc4V4ptkzWDUVwYvawm6gfM+AZ6EaKzf8uGe69rBg4 weDc4ldki+Bq59GJJWzDDNYTIsZpf2fdiEMoPnafPQocrt5TY3Yl4JBoPTYHZjB7Pj6/ ZQdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=yfpwU+zCCZGc3nefn+EMvc88RoIA2cnvWHJ72OfJayg=; b=emTLthMAV3dvX//Hc79JcIz/VLoDHzOqufTJl0ZdB39XW0vjw2jY5OPzrwGm8eVdxA rm8B3N+757uzL5rLBY6rgmFTz+eXKCMLSM/MluI/aE9BInQXdgqAoX5Bshq6WozkkwaH SF6c66iB9D/KIE+5JFDh6I9P6ULaCWP+22nwuvDwjzU1+jFMCh4sprV1unmpgGM0y0kP YYtc6Knko+S/tasiL6MKqfYK0271A1TcAYHMNROZSc4y2LRHtcz4jD7W5gfVDLXlO4Bo n1SekI2P/l4Rm1PIz0po9aMpBSrTz27ojAGdiy1stp1D3yFN4LtvmYiXsPEBkEzSdL0F H4NA== ARC-Authentication-Results: i=1; mx.google.com; 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 i2si12146514ejp.181.2021.06.06.12.25.10; Sun, 06 Jun 2021 12:25:34 -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; 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 S230155AbhFFTZU (ORCPT + 99 others); Sun, 6 Jun 2021 15:25:20 -0400 Received: from gate.crashing.org ([63.228.1.57]:38735 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbhFFTZS (ORCPT ); Sun, 6 Jun 2021 15:25:18 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 156JJABB011187; Sun, 6 Jun 2021 14:19:10 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 156JJ9oV011186; Sun, 6 Jun 2021 14:19:09 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sun, 6 Jun 2021 14:19:09 -0500 From: Segher Boessenkool To: Linus Torvalds Cc: Alan Stern , "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 Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: <20210606191909.GZ18427@gate.crashing.org> References: <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> <20210606125955.GT18427@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 06, 2021 at 11:25:46AM -0700, Linus Torvalds wrote: > On Sun, Jun 6, 2021 at 6:03 AM Segher Boessenkool > wrote: > > > > On Sat, Jun 05, 2021 at 08:41:00PM -0700, Linus Torvalds wrote: > > > > > > I think it's something of a bug when it comes to "asm volatile", but > > > the documentation isn't exactly super-specific. > > > > Why would that be? "asm volatile" does not prevent optimisation. > > Sure it does. > > That's the whole and only *POINT* of the "volatile". > > It's the same as a vol;atile memory access. That very much prevents > certain optimizations. You can't just join two volatile reads or > writes, because they have side effects. You can though. In exactly this same way: volatile int x; void g(int); void f(int n) { if (n) g(x); else g(x); } ==> f: movl x(%rip), %edi jmp g You can do whatever you want with code with side effects. The only thing required is that the side effects are executed as often as before and in the same order. Merging identical sides of a diamond is just fine. > And the exact same thing is true of inline asm. Even when they are > *identical*, inline asms have side effects that gcc simply doesn't > understand. Only volatile asm does (including all asm without outputs). But that still does not mean GCC cannot manipulate the asm! > And yes, those side effects can - and do - include "you can't just merge these". They do not. That is not what a side effect is. > > It says this code has some unspecified side effect, and that is all! > > And that should be sufficient. But gcc then violates it, because gcc > doesn't understand the side effects. > > Now, the side effects may be *subtle*, but they are very very real. > Just placement of code wrt a branch will actually affect memory > ordering, as that one example was. You have a different definition of "side effect" than C does apparently. 5.1.2.3/2: Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression in general includes both value computations and initiation of side effects. Value computation for an lvalue expression includes determining the identity of the designated object. > But that's what we need a compiler barrier for in the first place - > the compiler certainly doesn't understand about this very subtle > memory ordering issue, and we want to make sure that the code sequence > *remains* that "if A then write B". The compiler doesn't magically understand your intention, no. Some real work will need to be done to make this work. Segher