Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5159792pxj; Wed, 9 Jun 2021 10:28:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHRumGu4QUJnoP3NkuyR0jNCOZl1hZIPXgYvafjTQ+AeGfxD75lePWxbeCxIZjQLzwkAg0 X-Received: by 2002:a17:906:5285:: with SMTP id c5mr918882ejm.282.1623259699436; Wed, 09 Jun 2021 10:28:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623259699; cv=none; d=google.com; s=arc-20160816; b=0LcYE3mVInASdUskE0t9yHM7QnHq8kjccB0hcw/3GfLulpMAWQkK17cACbj/oCbMTf EtKHI+DAlKJCdVhtbLldFzzDHlgXNjWg6hHDAAG/Wj/JGlH+fsbEDd3ELXyAdXfKDE+z obh6DSJeSq8KTddjSzAeBfmRZLIDo41FlMNKFX6jAufv4fvUCafp0O4j+rVKmkzpTgeh nIGMnGMARWkZxln1tpGwEttk455pf4nj8rarNOWYRrAlJxxrhyEmTAzuLkDOlqJWjpkH 7JQ/DaYQBQHQGwKBAcG2wdmLZNMNtvW8pg6B6AMON/0VMbJehYaY3ztGNn7JPioijLwE T8mw== 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=3yJJiLIio1keCrN3sS6SLKCpX1mujUdD6B7dJpQDmZw=; b=sqJsPzxeeoMpHTnbwDXcugbQhwH0FRdkpcLf+v213LMi/EazoTw2Tkd+gqYXnfBhJ6 x9qc96kDohPMJP2Jo0TB1ZM0xBBAlqyKwuxsWeU6OKhdV1/1Sz5T8PPcQXUqSqRfBSft cV0zx8hatjQ/AfCFvB8ulQt2fHb6fDZFibwvmsYU3ix1XGY2N1dLikMHs7iBy0F/WgeX sPm4MKBsioMrTelBwztGS5ETz3+V27pWXHhrTF0SyGBtyDvjILUp73tn2CSnv2IATGly 86iz0YztsXb7wYcJQFjyOoivmkPfF5PaLyvxntRwCi7Pb19Rth0OEE7aie1L53T/qSYe +wQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ClaMFpHv; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z20si282947ejl.62.2021.06.09.10.27.43; Wed, 09 Jun 2021 10:28:19 -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=@google.com header.s=20161025 header.b=ClaMFpHv; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230393AbhFIMqf (ORCPT + 99 others); Wed, 9 Jun 2021 08:46:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229588AbhFIMqZ (ORCPT ); Wed, 9 Jun 2021 08:46:25 -0400 Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 377C4C06175F for ; Wed, 9 Jun 2021 05:44:21 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id o17-20020a9d76510000b02903eabfc221a9so10053389otl.0 for ; Wed, 09 Jun 2021 05:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3yJJiLIio1keCrN3sS6SLKCpX1mujUdD6B7dJpQDmZw=; b=ClaMFpHvFaLfrDBK3kLKjFrPN25oDeFJ8tj4sFgK8pktGD85GvHUBtvOEsfyTrqG+I X43sS+oC0NRnqBvv8fR1xouf7sOrSY40TyPaku3k/CIFeBOer4oWe3WdkZs3Y87sDPi1 nwgQ20qYboPzcGIJAvt5TjOrlRETQHfZEUR7OltE3NHxr3c9RcnfZ3cmaJf/dPCYX3ef fMHflwpyJCzqjK1hMUJMR9iwk1xuXRiFUVpKHGOUwyUgHq/A6y5pIbcT6NAUY4R14aqL ifxOAIMzLy60OeGyhY9jogUi7U8CrYZT4aUt6xV0uk0KViOaVef+3MfdSSup8dQZllAj 1xUw== 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=3yJJiLIio1keCrN3sS6SLKCpX1mujUdD6B7dJpQDmZw=; b=CBPsJyAAqdGY/MHtrk8zK5Y+tg4tR/piOnIN6H6Pck9CFVXW5qSSsLOmYhGPoHyFrs aB1I2NhyOMIWBCtWYMiTfoDzeMEDnv7jsfIbtZgclrRp0hdKIV7ikj7VzPISm4EpAxuP mO0LejPsw0Impu1ly8RzNZdfpUNPcugzo31y50Q6kGSfW/9Q7Uw4J5LixReUx+3nQ+t2 WvFFARERrl+ljidpts5E9sPD0HV4UA7FdOafya+ZLzIqiF1VByIBYTLacGzK1cQrWaF/ BiQEMy1IYaKUm9VGrsbYPaXCkxgaRE3n//ZX8ZGVDxrI4N4tGtqt0jGjSK7PJRtUelcE 8EuQ== X-Gm-Message-State: AOAM531F+/AZEg9olAUAELv75jN4pgIWSS8PLGgmDROqNWqYw8jNfaya 7LTb9FgWC4ELov6ku/ejx5qXK+7qEApbu/ejeyjMXw== X-Received: by 2002:a05:6830:1c7b:: with SMTP id s27mr8892653otg.233.1623242660230; Wed, 09 Jun 2021 05:44:20 -0700 (PDT) MIME-Version: 1.0 References: <20210606185922.GF7746@tucnak> <20210607152806.GS4397@paulmck-ThinkPad-P17-Gen-1> <20210608152851.GX18427@gate.crashing.org> In-Reply-To: <20210608152851.GX18427@gate.crashing.org> From: Marco Elver Date: Wed, 9 Jun 2021 14:44:08 +0200 Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: Segher Boessenkool Cc: Peter Zijlstra , "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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jun 2021 at 17:30, Segher Boessenkool wrote: > 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. There is a valid concern that something at the level of the memory model requires very precise specification in terms of language semantics and not generated code. Otherwise it seems difficult to get compiler folks onboard. And coming up with such a specification may take a while, especially if we have to venture in the realm of the C11/C++11 memory model while still trying to somehow make it work for the LKMM. That seems like a very tricky maze we may want to avoid. An alternative design would be to use a statement attribute to only enforce (C) ("__attribute__((mustcontrol))" ?). The rest can be composed through existing primitives I think (the compiler barriers need optimizing though), which should give us ctrl_depends(). At least for Clang, it should be doable: https://reviews.llvm.org/D103958 Thanks, -- Marco