From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Laight <David.Laight@aculab.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] net: Remove branch in csum_shift()
Date: Mon, 14 Feb 2022 03:29:18 -0600 [thread overview]
Message-ID: <20220214092918.GZ614@gate.crashing.org> (raw)
In-Reply-To: <476aa649389345db92f86e9103a848be@AcuMS.aculab.com>
On Sun, Feb 13, 2022 at 05:47:52PM +0000, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 13 February 2022 09:16
> > In an ideal world the compiler could choose the optimal code sequences
> > everywhere. But that won't ever happen, the search space is way too
> > big. So compilers just use heuristics, not exhaustive search like
> > superopt does. There is a middle way of course, something with directed
> > searches, and maybe in a few decades systems will be fast enough. Until
> > then we will very often see code that is 10% slower and 30% bigger than
> > necessary. A single insn more than needed isn't so bad :-)
>
> But it can be a lot more than that.
Obviously, but that isn't the case here (for powerpc anyway). My point
here is that you won't ever get ideal generated code from your high-
level code (which is what C is), certainly not for all architectures.
But it *is* possible to get something reasonably good.
> > Making things branch-free is very much worth it here though!
>
> I tried to find out where 'here' is.
I meant "with this patch".
Unpredictable branches are very expensive. They already were something
to worry about on single-issue in-order processors, but they are much
more expensive now.
> I can't get godbolt to generate anything like that object code
> for a call to csum_shift().
>
> I can't actually get it to issue a rotate (x86 of ppc).
All powerpc rotate insns start with "rl", and no other insns do. There
also are extended mnemonics to ease programming, like "rotlw", which is
just a form of rlwinm (rotlw d,s,n is rlwnm d,s,n,0,31).
Depending on what tool you use to display binary code it will show you
extended mnemonics for some insns or just the basic insns.
> I think it is only a single instruction because the compiler
> has saved 'offset & 1' much earlier instead of doing testing
> 'offset & 1' just prior to the conditional.
rlwinm -- "nm" means "and mask". rlwnm d,s,n,mb,me rotates register s
left by the contents of register n bits, and logical ands it with the
mask from bit mb until bit me.
> It certainly has a nasty habit of doing that pessimisation.
? Not sure what you mean here.
> I also suspect that the addc/addze pair could be removed
> by passing the old checksum into csum_partial.
Maybe? Does it not have to return a reduced result here?
Segher
next prev parent reply other threads:[~2022-02-14 9:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 8:48 [PATCH] net: Remove branch in csum_shift() Christophe Leroy
2022-02-13 2:39 ` David Laight
2022-02-13 9:16 ` Segher Boessenkool
2022-02-13 17:47 ` David Laight
2022-02-14 9:29 ` Segher Boessenkool [this message]
2022-03-01 10:20 ` Christophe Leroy
2022-03-01 10:47 ` David Laight
2022-03-01 11:14 ` Christophe Leroy
2022-03-01 11:41 ` David Laight
2022-03-01 12:37 ` Russell King (Oracle)
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=20220214092918.GZ614@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=David.Laight@aculab.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.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).