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, URIBL_BLOCKED,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 F2FE3C4743F for ; Sun, 6 Jun 2021 20:30:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8477613C7 for ; Sun, 6 Jun 2021 20:30:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230078AbhFFUc1 (ORCPT ); Sun, 6 Jun 2021 16:32:27 -0400 Received: from gate.crashing.org ([63.228.1.57]:54568 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229723AbhFFUcZ (ORCPT ); Sun, 6 Jun 2021 16:32:25 -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 156KQInJ013180; Sun, 6 Jun 2021 15:26:18 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 156KQGXe013177; Sun, 6 Jun 2021 15:26:16 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sun, 6 Jun 2021 15:26:16 -0500 From: Segher Boessenkool To: Linus Torvalds Cc: Alan Stern , "Paul E. McKenney" , Peter Zijlstra , 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: <20210606202616.GC18427@gate.crashing.org> References: <20210605145739.GB1712909@rowland.harvard.edu> <20210606001418.GH4397@paulmck-ThinkPad-P17-Gen-1> <20210606012903.GA1723421@rowland.harvard.edu> <20210606115336.GS18427@gate.crashing.org> <20210606184021.GY18427@gate.crashing.org> <20210606195242.GA18427@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-kernel@vger.kernel.org On Sun, Jun 06, 2021 at 01:11:53PM -0700, Linus Torvalds wrote: > On Sun, Jun 6, 2021 at 12:56 PM Segher Boessenkool > wrote: > > > > Yes, I know. But it is literally the *only* way to *always* get a > > conditional branch: by writing one. > > The thing is, I don't actually believe you. Fortune favours the bold! > The barrier() thing can work - all we need to do is to simply make it > impossible for gcc to validly create anything but a conditional > branch. And the only foolproof way of doing that is by writing a branch. > If either side of the thing have an asm that cannot be combined, gcc > simply doesn't have any choice in the matter. There's no other valid > model than a conditional branch around it (of some sort - doing an > indirect branch that has a data dependency isn't wrong either, it just > wouldn't be something that a sane compiler would generate because it's > obviously much slower and more complicated). Or push something to the stack and return. Or rewrite the whole thing as an FSM. Or or or. (And yes, there are existing compilers that can do both of these things on some code). > We are very used to just making the compiler generate the code we > need. That is, fundamentally, what any use of inline asm is all about. > We want the compiler to generate all the common cases and all the > regular instructions. > > The conditional branch itself - and the instructions leading up to it > - are exactly those "common regular instructions" that we'd want the > compiler to generate. That is in fact more true here than for most > inline asm, exactly because there are so many different possible > combinations of conditional branches (equal, not equal, less than,..) > and so many ways to generate the code that generates the condition. > > So we are much better off letting the compiler do all that for us - > it's very much what the compiler is good at. Yes, exactly. I am saying that if you depend on that some C code you write will result in some particular machine code, without actually *forcing* the compiler to output that exact machine code, then you will be disappointed. Maybe not today, and maybe it will take years, if you are lucky. (s/forcing/instructing/ of course, compilers have feelings too!) Segher