Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp346235pxb; Wed, 14 Apr 2021 17:23:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+y5WN9xGQoH/2ZzyT0Lp8ZrJBckBE6ic9ff6powtj8p7kLubVSr+BgDedeN1IARwycBXL X-Received: by 2002:a17:906:46d6:: with SMTP id k22mr647044ejs.243.1618446211788; Wed, 14 Apr 2021 17:23:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618446211; cv=none; d=google.com; s=arc-20160816; b=J0QZns3R+HmGNwiGxwLuNiZejfwZ67TLGG1qK+vztLoL4ycBnXodn+Zyc0aPIu+ppE fKj0Sd/iVy8kXvODRen3qPHB98PkIUym7kOGzTmzQ6+dL9Gw2voQQwYsx75sdRFrWkR1 gJXQHrZW8Pi0QEXOIruqiLSAtEbfar7mSW4G+O8ZvajGJB+iN0UEqEXzhycKr+V+IcEy 5Aarf8wIGmyWnbuC8uaRmokcPCpvBVKn7LN/vlAYC6JTLKhl+FP7AdgPLjxoKCKEG71d BJAj1jH55X4du7yL2S+E4pUHoGSq2HMstQGeDIWQ7MakiLzcQAghautn89/F6G7++0DJ hN9A== 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=a6dl2w2bW1d38EnN/q3tp9q3lvF37Lpj0KnoUTXQhow=; b=KvUcZXD5K/tzVWX0McayQQiQ3psCvvgQyetUwRDZtgFvY6w3N1lrIu5HxcUrc5R0vn KgsoVeLu/urCHbvZ2lJRXXdZymIgMlLGgzs6s352IUfQ6XPsPcwN5XHbvTTPOeWoJhx7 UYPL8xtYZciD1ATfzY5dAc0Zhz/lIyYX3nNnoVSujBWaizcBLHLE0tp3MQJA5Ns0HqTC RyORbmtkY8oZjBfA4UOLfDh53ewUDjf2NZiy6CiblgwqMNZssRfsGURbFshaBfjsvNNo Hp2m9htIzJ7OoAHJ4wgXZ02atO8JjWxZ5VySJ+8RAv0b6YBa80Q/q5TRGheBystf7dKz qomw== 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 jl15si731742ejc.18.2021.04.14.17.23.08; Wed, 14 Apr 2021 17:23:31 -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 S230188AbhDNMaB (ORCPT + 99 others); Wed, 14 Apr 2021 08:30:01 -0400 Received: from gate.crashing.org ([63.228.1.57]:43627 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229765AbhDNMaA (ORCPT ); Wed, 14 Apr 2021 08:30:00 -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 13ECO93T019063; Wed, 14 Apr 2021 07:24:09 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 13ECO99U019061; Wed, 14 Apr 2021 07:24:09 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 14 Apr 2021 07:24:09 -0500 From: Segher Boessenkool To: Nicholas Piggin Cc: Christophe Leroy , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Paul Mackerras Subject: Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible Message-ID: <20210414122409.GV26583@gate.crashing.org> References: <09da6fec57792d6559d1ea64e00be9870b02dab4.1617896018.git.christophe.leroy@csgroup.eu> <20210412215428.GM26583@gate.crashing.org> <20210413215803.GT26583@gate.crashing.org> <1618365589.67fxh7cot9.astroid@bobo.none> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1618365589.67fxh7cot9.astroid@bobo.none> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote: > Would be nice if we could let the compiler deal with it all... > > static inline unsigned long lr(unsigned long *mem) > { > unsigned long val; > > /* > * This doesn't clobber memory but want to avoid memory operations > * moving ahead of it > */ > asm volatile("ldarx %0, %y1" : "=r"(val) : "Z"(*mem) : "memory"); > > return val; > } (etc.) That can not work reliably: the compiler can put random instructions between the larx and stcx. this way, and you then do not have guaranteed forward progress anymore. It can put the two in different routines (after inlining and other interprocedural optimisations), duplicate them, make a different number of copies of them, etc. Nothing of that is okay if you want to guarantee forward progress on all implementations, and also not if you want to have good performance everywhere (or anywhere even). Unfortunately you have to write all larx/stcx. loops as one block of assembler, so that you know exactly what instructions will end up in your binary. If you don't, it will fail mysteriously after random recompilations, or have performance degradations, etc. You don't want to go there :-) Segher