From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH RFC 2/4] include/linux/compiler.h: allow memory operands Date: Mon, 7 Jan 2019 17:54:27 +0000 Message-ID: <20190107175427.GB22911@fuggles.cambridge.arm.com> References: <20190102205715.14054-1-mst@redhat.com> <20190102205715.14054-3-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190102205715.14054-3-mst@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "Michael S. Tsirkin" Cc: Andrea Parri , linux-arch@vger.kernel.org, "Paul E. McKenney" , Peter Zijlstra , Daniel Lustig , Akira Yokosawa , linux-kernel@vger.kernel.org, Nicholas Piggin , virtualization@lists.linux-foundation.org, David Howells , linux-sparse@vger.kernel.org, Alan Stern , netdev@vger.kernel.org, Luc Maranget , Jade Alglave , Boqun Feng , Luc Van Oostenryck List-Id: linux-sparse@vger.kernel.org On Wed, Jan 02, 2019 at 03:57:54PM -0500, Michael S. Tsirkin wrote: > We don't really care whether the variable is in-register > or in-memory. Relax the constraint accordingly. > > Signed-off-by: Michael S. Tsirkin > --- > include/linux/compiler.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 1ad367b4cd8d..6601d39e8c48 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -154,7 +154,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, > #ifndef OPTIMIZER_HIDE_VAR > /* Make the optimizer believe the variable can be manipulated arbitrarily. */ > #define OPTIMIZER_HIDE_VAR(var) \ > - __asm__ ("" : "=r" (var) : "0" (var)) > + __asm__ ("" : "=rm" (var) : "0" (var)) > #endif I think this can break for architectures with write-back addressing modes such as arm, where the "m" constraint is assumed to be evaluated precisely once in the asm block. Will