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,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 B2F26C432BE for ; Thu, 26 Aug 2021 12:52:56 +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 EBBD460184 for ; Thu, 26 Aug 2021 12:52:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EBBD460184 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 4GwN6t1MYNz2yw6 for ; Thu, 26 Aug 2021 22:52:54 +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 4GwN6M2RL7z2yNN for ; Thu, 26 Aug 2021 22:52:26 +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 17QCn2jm014844; Thu, 26 Aug 2021 07:49:02 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 17QCn1dS014838; Thu, 26 Aug 2021 07:49:01 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 26 Aug 2021 07:49:01 -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: <20210826124901.GY1583@gate.crashing.org> References: <1628834356.pr4zgn1xf1.astroid@bobo.none> <20210818150653.GJ1583@gate.crashing.org> <1629946707.f6ptz0tgle.astroid@bobo.none> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1629946707.f6ptz0tgle.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" Hi! On Thu, Aug 26, 2021 at 01:26:14PM +1000, Nicholas Piggin wrote: > Excerpts from Segher Boessenkool's message of August 19, 2021 1:06 am: > > 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? > > Taken branches are fetched by the front end at one per cycle (assuming > they hit the BTAC), but all branches have to be executed by BR at one > per cycle This is not true. (Simple) predicted not-taken conditional branches are just folded out, never hit the issue queues. And they are fetched as many together as fit in a fetch group, can complete without limits as well. The BTAC is a frontend thing, used for target address prediction. It does not limit execution. Correctly predicted simple conditional branches just get their prediction validated (and that is not done in the execution units). Incorrectly predicted branches the same, but those cause a redirect and refetch. > > 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. > > I did take a look at it at one point. > > One problem is that the kernel needs the address of the trap instruction > to create the entry for it. The other problem is that __builtin_trap > does not return so it can't be used for WARN. LLVM at least seems to > have a __builtin_debugtrap which does return. This is . > The first problem seems like the show stopper though. AFAIKS it would > need a special builtin support that does something to create the table > entry, or a guarantee that we could put an inline asm right after the > builtin as a recognized pattern and that would give us the instruction > following the trap. I'm not quite sure what this means. Can't you always just put a bla: asm(""); in there, and use the address of "bla"? If not, you need to say a lot more about what you actually want to do :-/ Segher