From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0DCAC48BCF for ; Wed, 9 Jun 2021 15:37:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C342661285 for ; Wed, 9 Jun 2021 15:37:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232972AbhFIPjd (ORCPT ); Wed, 9 Jun 2021 11:39:33 -0400 Received: from gate.crashing.org ([63.228.1.57]:47811 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234049AbhFIPjF (ORCPT ); Wed, 9 Jun 2021 11:39:05 -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 159FVcVo029586; Wed, 9 Jun 2021 10:31:38 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 159FVXoX029584; Wed, 9 Jun 2021 10:31:33 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 9 Jun 2021 10:31:33 -0500 From: Segher Boessenkool To: Marco Elver 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 Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: <20210609153133.GF18427@gate.crashing.org> References: <20210607152806.GS4397@paulmck-ThinkPad-P17-Gen-1> <20210608152851.GX18427@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-arch@vger.kernel.org On Wed, Jun 09, 2021 at 02:44:08PM +0200, Marco Elver wrote: > On Tue, 8 Jun 2021 at 17:30, Segher Boessenkool > wrote: > > 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. Yup, exactly. Especially because the meaning of generated code is hard to describe, and even much more so if you do not limit yourself to a single machine architecture. > Otherwise it seems difficult to get > compiler folks onboard. It isn't just difficult to get us on board without it, we know it just is impossible to do anything sensible without it. > And coming up with such a specification may > take a while, Yes. > 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. Well, you only need to use the saner parts of the memory model (not the full thing), and extensions are fine as well of course. > An alternative design would be to use a statement attribute to only > enforce (C) ("__attribute__((mustcontrol))" ?). Statement attributes only exist for empty statements. It is unclear how (and if!) we could support it for general statements. Some new builtin seems to fit the requirements better? I haven't looked too closely though. Segher