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: Sun, 13 Feb 2022 03:16:19 -0600 [thread overview]
Message-ID: <20220213091619.GY614@gate.crashing.org> (raw)
In-Reply-To: <7f16910a8f63475dae012ef5135f41d1@AcuMS.aculab.com>
On Sun, Feb 13, 2022 at 02:39:06AM +0000, David Laight wrote:
> From: Christophe Leroy
> > Sent: 11 February 2022 08:48
> >
> > Today's implementation of csum_shift() leads to branching based on
> > parity of 'offset'
> >
> > 000002f8 <csum_block_add>:
> > 2f8: 70 a5 00 01 andi. r5,r5,1
> > 2fc: 41 a2 00 08 beq 304 <csum_block_add+0xc>
> > 300: 54 84 c0 3e rotlwi r4,r4,24
> > 304: 7c 63 20 14 addc r3,r3,r4
> > 308: 7c 63 01 94 addze r3,r3
> > 30c: 4e 80 00 20 blr
> >
> > Use first bit of 'offset' directly as input of the rotation instead of
> > branching.
> >
> > 000002f8 <csum_block_add>:
> > 2f8: 54 a5 1f 38 rlwinm r5,r5,3,28,28
> > 2fc: 20 a5 00 20 subfic r5,r5,32
> > 300: 5c 84 28 3e rotlw r4,r4,r5
> > 304: 7c 63 20 14 addc r3,r3,r4
> > 308: 7c 63 01 94 addze r3,r3
> > 30c: 4e 80 00 20 blr
> >
> > And change to left shift instead of right shift to skip one more
> > instruction. This has no impact on the final sum.
> >
> > 000002f8 <csum_block_add>:
> > 2f8: 54 a5 1f 38 rlwinm r5,r5,3,28,28
> > 2fc: 5c 84 28 3e rotlw r4,r4,r5
> > 300: 7c 63 20 14 addc r3,r3,r4
> > 304: 7c 63 01 94 addze r3,r3
> > 308: 4e 80 00 20 blr
>
> That is ppc64.
That is 32-bit powerpc.
> What happens on x86-64?
>
> Trying to do the same in the x86 ipcsum code tended to make the code worse.
> (Although that test is for an odd length fragment and can just be removed.)
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 :-)
Making things branch-free is very much worth it here though!
Segher
next prev parent reply other threads:[~2022-02-13 9:19 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 [this message]
2022-02-13 17:47 ` David Laight
2022-02-14 9:29 ` Segher Boessenkool
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=20220213091619.GY614@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).