From: David Laight <David.Laight@ACULAB.COM>
To: 'Segher Boessenkool' <segher@kernel.crashing.org>
Cc: 'Christophe Leroy' <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] net: Remove branch in csum_shift()
Date: Sun, 13 Feb 2022 17:47:52 +0000 [thread overview]
Message-ID: <476aa649389345db92f86e9103a848be@AcuMS.aculab.com> (raw)
In-Reply-To: <20220213091619.GY614@gate.crashing.org>
From: Segher Boessenkool
> Sent: 13 February 2022 09:16
....
>
> > 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 :-)
But it can be a lot more than that.
> Making things branch-free is very much worth it here though!
I tried to find out where 'here' is.
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).
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.
It certainly has a nasty habit of doing that pessimisation.
So while it helps a specific call site it may be much
worse in general.
I also suspect that the addc/addze pair could be removed
by passing the old checksum into csum_partial.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-02-13 17:48 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 [this message]
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=476aa649389345db92f86e9103a848be@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=christophe.leroy@csgroup.eu \
--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 \
--cc=segher@kernel.crashing.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).