From: Segher Boessenkool <segher@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
Date: Wed, 18 Aug 2021 10:06:53 -0500 [thread overview]
Message-ID: <20210818150653.GJ1583@gate.crashing.org> (raw)
In-Reply-To: <1628834356.pr4zgn1xf1.astroid@bobo.none>
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
next prev parent reply other threads:[~2021-08-18 15:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 16:38 [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Christophe Leroy
2021-04-13 16:38 ` [PATCH v2 2/2] powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto Christophe Leroy
2021-08-13 6:19 ` Nicholas Piggin
2021-08-15 3:49 ` Michael Ellerman
2021-08-25 21:25 ` Nathan Chancellor
2021-08-26 3:21 ` Michael Ellerman
2021-08-26 6:37 ` Christophe Leroy
2021-08-26 13:47 ` Segher Boessenkool
2021-08-26 14:45 ` Michael Ellerman
2021-08-26 14:53 ` Christophe Leroy
2021-08-26 14:12 ` Segher Boessenkool
2021-08-26 18:54 ` Nathan Chancellor
2021-08-26 23:55 ` Nathan Chancellor
2021-08-27 7:53 ` Michael Ellerman
2021-08-13 6:08 ` [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32 Nicholas Piggin
2021-08-18 15:06 ` Segher Boessenkool [this message]
2021-08-26 3:26 ` Nicholas Piggin
2021-08-26 12:49 ` Segher Boessenkool
2021-08-26 13:57 ` Nicholas Piggin
2021-08-26 14:37 ` Segher Boessenkool
2021-08-26 15:04 ` Nicholas Piggin
2021-08-26 15:30 ` Segher Boessenkool
2021-08-27 1:28 ` Nicholas Piggin
2021-08-18 13:38 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210818150653.GJ1583@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).