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 21F4FC48BCF for ; Wed, 9 Jun 2021 17:19:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 06AEB61027 for ; Wed, 9 Jun 2021 17:19:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231396AbhFIRVm (ORCPT ); Wed, 9 Jun 2021 13:21:42 -0400 Received: from gate.crashing.org ([63.228.1.57]:44663 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231290AbhFIRVl (ORCPT ); Wed, 9 Jun 2021 13:21:41 -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 159HELK2003025; Wed, 9 Jun 2021 12:14:21 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 159HEJl9003023; Wed, 9 Jun 2021 12:14:19 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 9 Jun 2021 12:14:19 -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: <20210609171419.GI18427@gate.crashing.org> References: <20210607152806.GS4397@paulmck-ThinkPad-P17-Gen-1> <20210608152851.GX18427@gate.crashing.org> <20210609153133.GF18427@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 06:13:00PM +0200, Marco Elver wrote: > On Wed, 9 Jun 2021 at 17:33, Segher Boessenkool > wrote: > [...] > > > 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. > > Statement attributes can apply to anything -- Clang has had them apply > to non-empty statements for a while. First off, it is not GCC's problem if LLVM decides to use a GCC extension in some non-compatible way. It might be possible to extend statement attributes to arbitrary statement expressions, or some subset of statement expressions, but that then has to be written down as well; it isn't obvious at all what this woould do. > In fact, since C++20 [3], GCC will have to support statement > attributes on non-empty statements, so presumably the parsing logic > should already be there. > [3] https://en.cppreference.com/w/cpp/language/attributes/likely C++ attributes have different syntax *and semantics*. With GCC attributes it isn't clear what statement something belongs to (a statement can contain a statement after all). C++ requires all unknown attributes to be ignored without error, so can this be useful at all here? > > Some new builtin seems to fit the requirements better? I haven't looked > > too closely though. > > I had a longer discussion with someone offline about it, and the > problem with a builtin is similar to the "memory_order_consume > implementation problem" -- you might have an expression that uses the > builtin in some function without any control, and merely returns the > result of the expression as a result. If that function is in another > compilation unit, it then becomes difficult to propagate this > information without somehow making it part of the type system. > Therefore, by using a statement attribute on conditional control > statements, we do not even have this problem. It seems cleaner > syntactically than having a __builtin_() that is either approximate, > or gives an error if used in the wrong context. You would use the builtin to mark exactly where you are making the control dependency. (And what is a "conditional control statement"? Yes of course I can imagine things, but that is not good enough at all). > Hence the suggestion for a very simple attribute, which also > side-steps this problem. And introduces many more problems :-( Segher