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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F3BAC433EF for ; Mon, 27 Jun 2022 14:56:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235008AbiF0O4L (ORCPT ); Mon, 27 Jun 2022 10:56:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231462AbiF0O4K (ORCPT ); Mon, 27 Jun 2022 10:56:10 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id E6584167CC for ; Mon, 27 Jun 2022 07:56:09 -0700 (PDT) Received: (qmail 121219 invoked by uid 1000); 27 Jun 2022 10:56:09 -0400 Date: Mon, 27 Jun 2022 10:56:09 -0400 From: Alan Stern To: Paul =?iso-8859-1?Q?Heidekr=FCger?= Cc: clang-built-linux , linux-toolchains@vger.kernel.org, Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , Tom Rix , Palmer Dabbelt , LKML , linux-arch , Marco Elver , Charalampos Mainas , Pramod Bhatotia , Soham Chakraborty , Martin Fink Subject: Re: [PATCH RFC] tools/memory-model: Adjust ctrl dependency definition Message-ID: References: <20220615114330.2573952-1-paul.heidekrueger@in.tum.de> <50B9D7C1-B11D-4583-9814-BFFF2C80D8CA@in.tum.de> <04B4DBD6-1262-4905-9E85-9466FC104895@in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <04B4DBD6-1262-4905-9E85-9466FC104895@in.tum.de> Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Mon, Jun 27, 2022 at 11:47:43AM +0200, Paul Heidekrüger wrote: > > > On 21. Jun 2022, at 16:24, Alan Stern wrote: > > > > On Tue, Jun 21, 2022 at 01:59:27PM +0200, Paul Heidekrüger wrote: > >> OK. So, LKMM limits the scope of control dependencies to its arm(s), hence > >> there is a control dependency from the last READ_ONCE() before the loop > >> exists to the WRITE_ONCE(). > >> > >> But then what about the following: > >> > >>> int *x, *y; > >>> > >>> int foo() > >>> { > >>> /* More code */ > >>> > >>> if(READ_ONCE(x)) > >>> return 42; > >>> > >>> /* More code */ > >>> > >>> WRITE_ONCE(y, 42); > >>> > >>> /* More code */ > >>> > >>> return 0; > >>> } > >> > >> The READ_ONCE() determines whether the WRITE_ONCE() will be executed at all, > >> but the WRITE_ONCE() doesn't lie in the if condition's arm. > > > > So in this case the LKMM would not recognize that there's a control > > dependency, even though it clearly exists. > > Oh, that's unfortunate. > > Then I would still argue that the "at all" definition is misleading. This I agree, and I would welcome a patch improving the definition. Perhaps something along the lines of what I wrote earlier in this email thread. > time in the other direction as I had initially proposed though, as the above > example is a case where "at all" holds true, but LKMM doesn't cover it. Or > do you think that caveating this in litmus-tests.txt, e.g. via the patch we > had recently worked out [1], is enough? No, the explanation should be improved. Alan