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=-4.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, TVD_SUBJ_WIPE_DEBT,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 84543C4338F for ; Wed, 18 Aug 2021 15:10:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 50E7760E76 for ; Wed, 18 Aug 2021 15:10:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 50E7760E76 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4GqWYg4M1gz3d8G for ; Thu, 19 Aug 2021 01:10:47 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=permerror (SPF Permanent Error: Unknown mechanism found: ip:192.40.192.88/32) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 4GqWY760L2z3bhb for ; Thu, 19 Aug 2021 01:10:19 +1000 (AEST) 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 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 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org, Paul Mackerras , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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