Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp545312pxb; Wed, 18 Aug 2021 08:15:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcYgXWSGzeuc8DUtAhI1Hz58YZrHREnBvxxdu4JifMMJDoVZ0TW9NxSno5sBpje7noVMWB X-Received: by 2002:a92:8742:: with SMTP id d2mr6444926ilm.58.1629299758121; Wed, 18 Aug 2021 08:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629299758; cv=none; d=google.com; s=arc-20160816; b=h2aB2dNAOAqA8aBSS19gGbeH0ZXEzaHJ+7/76MFucPCMhGSHCSQ5xxr8n/4htj34Gm GtZsaUayyVX/Ycjqy66cxnbgKMDhkeoBsHPPx+0qoaZeLfIWbnh+s/9RKHYDAZq5TtRi 9ZXLlxLBh3p4hc7QF0DnzaF62MpGYGS1qNRKYRQHmylEapCjDS1X6Dtbv2ipJDwLbWp/ fDyy1Yb0VH6ujx6U6ds/0zFl4TjWNUZIitLMdG9imJJ727fe5eQHew5/bc/4lXjuzMam /FJNCv/NYfPZHzEm+WJFCPomW3QNxxS8a1/k6fiEGH/SHmeau3kSz1xbLpxDxiSWcjWz +64w== 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=VNIIAxbRM1CijzrfmMZzAsnA6M602+9BWPiTBV8rWlw=; b=sAyf6lNNbjcWxBOxhux8HDCVNGMRvLVbdbVXUKlE8Bn9BMRnjq8h33M1U60/vwGKcQ KZpaiP4feiwFdbsuHCzEb13lswH3VP2d7dx3S3PkejMq6ZvfMBnqG5UtKBxoBrNJNmj5 WwYfX2w5KeJpuiPf9Uh5bBUelj0cg7nGzrU5XwUf3ya3BvQeobIQ7OSX1EE3TcoMe9xY KkGYfWbH5jKhedIoI1jhXmeCuBu0VGXbUqy/mWEwZAJ2aIdFgdITYTpug1NIvc25fgPp rJs6UrThxS9L+5j53ar83lwW8YEsav9z4br5KVYuWIK+kkuDi0m6ihr/o+po7XrTCb1Q rTgg== 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 w6si128516ilu.79.2021.08.18.08.15.42; Wed, 18 Aug 2021 08:15:58 -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 S239487AbhHRPOF (ORCPT + 99 others); Wed, 18 Aug 2021 11:14:05 -0400 Received: from gate.crashing.org ([63.228.1.57]:33052 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239042AbhHRPOE (ORCPT ); Wed, 18 Aug 2021 11:14:04 -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 17IF6smb011664; Wed, 18 Aug 2021 10:06:54 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 17IF6ric011660; Wed, 18 Aug 2021 10:06:53 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 18 Aug 2021 10:06:53 -0500 From: Segher Boessenkool To: Nicholas Piggin Cc: Benjamin Herrenschmidt , Christophe Leroy , Michael Ellerman , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Message-ID: <20210818150653.GJ1583@gate.crashing.org> References: <1628834356.pr4zgn1xf1.astroid@bobo.none> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1628834356.pr4zgn1xf1.astroid@bobo.none> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 13, 2021 at 04:08:13PM +1000, Nicholas Piggin wrote: > This one possibly the branches end up in predictors, whereas conditional > trap is always just speculated not to hit. Branches may also have a > throughput limit on execution whereas trap could be more (1 per cycle > vs 4 per cycle on POWER9). I thought only *taken* branches are just one per cycle? And those branches are only taken for the exceptional condition (or the case where we do not care about performance, anyway, if we do have an error most of the time ;-) ) > On typical ppc32 CPUs, maybe it's a more obvious win. As you say there > is the CFAR issue as well which makes it a problem for 64s. It would > have been nice if it could use the same code though. On 64-bit the code looks better for the no-error path as well. > Maybe one day gcc's __builtin_trap() will become smart enough around > conditional statements that it it generates better code and tries to > avoid branches. Internally *all* traps are conditional, in GCC. It also can optimise them quite well. There must be something in the kernel macros that prevents good optimisation. Segher