Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2173199pxb; Fri, 24 Sep 2021 23:23:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzTugSnJIEw0z2J5VTcsKGNm1RgqFLgLPyrgzeUKBvCPnhffYQYy5OLAl3ZlLID2AW0+n8t X-Received: by 2002:a92:290f:: with SMTP id l15mr11306146ilg.220.1632550989152; Fri, 24 Sep 2021 23:23:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632550989; cv=none; d=google.com; s=arc-20160816; b=GnJwlXk6MVZtLycjhUI1Q/d/jiVkG4B7e7GFc4h47i/NI1+Ye6fo9p49wqJtR40sg8 5PVdcyjb+voLyefKC3PieeIL8VUZw8vKahPdm6LjKJ/t+YisLGMz3zs04PcMc/R/v8sG gZy/q+5ba3rfllTb2zGuIGqDh0DAoY+kbM/clhW0t9nfNhPf0Z9ZNeX1eOAfIM/BRl7J zX1PbE6UIo2NUNdu1K7+ugK/TpKk2wk71WSnoI/E4e78cIk/9+ylWnMAovTVvbZlvlb7 tU5uHbni8TmzYkj8MV3FWrT6NQdErWgS565MZBESuieQUjRsYG2fzP0iykMcPf+Jypu/ vOSA== 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=zUF5mm9Jmu5UcZwTOd1sb58uLaVJtTDKey4fHZEQYMI=; b=qo3Fx7bNWrKY1wCJZyVPfhT2WHuqauiiDtlnpmwFOfrA13LJR4/xPP0L5JF1FGSOhE v/OjqfE8bpgJavN90bakT0YEfviwgJQD2/P0qffYUzMk8hBvpfR4i4LeMi6n4/jeAIOi l9+a5nOMEqr2N2Ugi5Jclb2DrdG1tDVqqbhapXmnxjM0IYi5QtXZvZwOer+hVFlfBCTk mWcJnqOItRYQFBwoIMfAgioB4Wkg/FKLqkYYyBvjzkGmQc0yY6kjUJ+JMZ0vngDMhggG L8aWAIZt2FLsCUfJp7TG/Fw+jSEXHkiP19uZaiOCCf7yZr9MQwJZsZVLcBx3GP53uLKc IZHw== 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 y15si12942716ilu.118.2021.09.24.23.22.58; Fri, 24 Sep 2021 23:23:09 -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 S1348307AbhIXUCr (ORCPT + 99 others); Fri, 24 Sep 2021 16:02:47 -0400 Received: from gate.crashing.org ([63.228.1.57]:60688 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345661AbhIXUCq (ORCPT ); Fri, 24 Sep 2021 16:02:46 -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 18OJtaHF002175; Fri, 24 Sep 2021 14:55:36 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 18OJtZvk002172; Fri, 24 Sep 2021 14:55:35 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 24 Sep 2021 14:55:35 -0500 From: Segher Boessenkool To: Mathieu Desnoyers Cc: Peter Zijlstra , Linus Torvalds , will@kernel.org, paulmck@kernel.org, stern@rowland.harvard.edu, parri.andrea@gmail.com, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: <20210924195535.GC17780@gate.crashing.org> References: <20210924183858.GA25901@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210924183858.GA25901@localhost> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Fri, Sep 24, 2021 at 02:38:58PM -0400, Mathieu Desnoyers wrote: > Following the LPC2021 BoF about control dependency, I re-read the kernel > documentation about control dependency, and ended up thinking that what > we have now is utterly fragile. > > Considering that the goal here is to prevent the compiler from being able to > optimize a conditional branch into something which lacks the control > dependency, while letting the compiler choose the best conditional > branch in each case, how about the following approach ? > > #define ctrl_dep_eval(x) ({ BUILD_BUG_ON(__builtin_constant_p((_Bool) x)); x; }) > #define ctrl_dep_emit_loop(x) ({ __label__ l_dummy; l_dummy: asm volatile goto ("" : : : "cc", "memory" : l_dummy); (x); }) > #define ctrl_dep_if(x) if ((ctrl_dep_eval(x) && ctrl_dep_emit_loop(1)) || ctrl_dep_emit_loop(0)) [The "cc" clobber only pessimises things: the asm doesn't actually clobber the default condition code register (which is what "cc" means), and you can have conditional branches using other condition code registers, or on other registers even (general purpose registers is common.] > The idea is to forbid the compiler from considering the two branches as > identical by adding a dummy loop in each branch with an empty asm goto. > Considering that the compiler should not assume anything about the > contents of the asm goto (it's been designed so the generated assembly > can be modified at runtime), then the compiler can hardly know whether > each branch will trigger an infinite loop or not, which should prevent > unwanted optimisations. The compiler looks if the code is identical, nothing more, nothing less. There are no extra guarantees. In principle the compiler could see both copies are empty asms looping to self, and so consider them equal. Segher