Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4656715pxj; Tue, 8 Jun 2021 21:24:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5ttjJC48skn0TbS1Up6LGEMfBTf8ZwwWTeXDyOjfMEU79yh7+0mnY5daeHOyIusoz6uBX X-Received: by 2002:a05:6402:416:: with SMTP id q22mr28833462edv.204.1623212686825; Tue, 08 Jun 2021 21:24:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623212686; cv=none; d=google.com; s=arc-20160816; b=0eGJxntZHUP+3kN6gtWUJiZDDYRcMV3eMJ15BHZjWKWKfe80WekZnYF3CKgw+IKAl5 dvHlMerGl0IRpDWhjy1ZGRR3jFGMq/lRRPSJJ0oZJ7zqpiHZsUkF9rf8yUcRCRI2glvr tdArjPMjah7dI0ulO8AT0ZYQoRI8j0KPk6IbwbllUxrBimENGXokZzkTDnT2uY7txwLU 7T/1VLhRyutq2kUtCA0v7YdZxuhthMeYz2l6M1baVE7ONTULDs/KLYSdQAsV+OkP9p3A enn0w6MYJUqtqbznLXMV1Ka8D77uCV4mK/oqEsRBJ7D/b0+LmwCecvOC83q72dvorG1M hDjQ== 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=WC2LXwyWYpFlGsGU04BsT8L21AR4VvX5F66HDMkUCx0=; b=MtfutZnR0tIf2ffJlBtpvTbnU2IisVdzrqZB967WPLL9LL6JbRYGDumxA6S6KUmYSZ tvXdrBOU8ahRxT/kbloYVcRLKlr3hMXYpbjuKWGk43wFOGuoMpJXJQVyOYDIRg+NTRLq tbCL4+/nM54zlQ+3vGNLrWo9VxisVRyKcSgR8DOnRz07svu/mhPwH9o1wdpERWFLrD/v GPlUJEJq8ZjnfZB6X1MHdHfO4DjwrxCVH2g0h9dYyIA7kJiFrEiVsOAMVEBOdWM9gPkd hw6EQK61ZxlRQ1OhbyJHAyePdr6Ko0tKEU5eg6guaM50+QUXxyLHZ9tKGfhkAAAS5ihq RlCg== 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 e24si1456337ejl.425.2021.06.08.21.24.23; Tue, 08 Jun 2021 21:24:46 -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 S232796AbhFHPgZ (ORCPT + 99 others); Tue, 8 Jun 2021 11:36:25 -0400 Received: from gate.crashing.org ([63.228.1.57]:34923 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231842AbhFHPgY (ORCPT ); Tue, 8 Jun 2021 11:36:24 -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 158FStNV014004; Tue, 8 Jun 2021 10:28:55 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 158FSp5w013994; Tue, 8 Jun 2021 10:28:51 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 8 Jun 2021 10:28:51 -0500 From: Segher Boessenkool To: Peter Zijlstra Cc: Marco Elver , "Paul E. McKenney" , Alexander Monakov , Linus Torvalds , Jakub Jelinek , Alan Stern , 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: <20210608152851.GX18427@gate.crashing.org> References: <20210606185922.GF7746@tucnak> <20210607152806.GS4397@paulmck-ThinkPad-P17-Gen-1> 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 Tue, Jun 08, 2021 at 01:22:58PM +0200, Peter Zijlstra wrote: > Works for me; and note how it mirrors how we implemented volatile_if() > in the first place, by doing an expression wrapper. > > __builtin_ctrl_depends(expr) would have to: > > - ensure !__builtin_const_p(expr) (A) Why would it be an error if __builtin_constant_p(expr)? In many programs the compiler can figure out some expression does never change. Having a control dependency on sometthing like that is not erroneous. > - imply an acquire compiler fence (B) > - ensure cond-branch is emitted (C) (C) is almost impossible to do. This should be reformulated to talk about the effect of the generated code, instead. > *OR* > > - ensure !__builtin_const_p(expr); (A) > - upgrade the load in @expr to load-acquire (D) So that will only work if there is exactly one read from memory in expr? That is problematic. This needs some work. Segher