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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 67BC6C433EF for ; Sun, 13 Feb 2022 17:48:29 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JxZZz1nR5z3bcS for ; Mon, 14 Feb 2022 04:48:27 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.85.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JxZZT3PrFz2xsS for ; Mon, 14 Feb 2022 04:47:59 +1100 (AEDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-186-LeVe8n1APwumlclMeJaqYQ-1; Sun, 13 Feb 2022 17:47:54 +0000 X-MC-Unique: LeVe8n1APwumlclMeJaqYQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Sun, 13 Feb 2022 17:47:52 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.028; Sun, 13 Feb 2022 17:47:52 +0000 From: David Laight To: 'Segher Boessenkool' Subject: RE: [PATCH] net: Remove branch in csum_shift() Thread-Topic: [PATCH] net: Remove branch in csum_shift() Thread-Index: AQHYHyQqmTo4K/pb5UWdDmTfE7rfRayQxWFwgABxD4CAAIxicA== Date: Sun, 13 Feb 2022 17:47:52 +0000 Message-ID: <476aa649389345db92f86e9103a848be@AcuMS.aculab.com> References: <7f16910a8f63475dae012ef5135f41d1@AcuMS.aculab.com> <20220213091619.GY614@gate.crashing.org> In-Reply-To: <20220213091619.GY614@gate.crashing.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jakub Kicinski , "linuxppc-dev@lists.ozlabs.org" , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Segher Boessenkool=20 > Sent: 13 February 2022 09:16 .... >=20 > > What happens on x86-64? > > > > Trying to do the same in the x86 ipcsum code tended to make the code wo= rse. > > (Although that test is for an odd length fragment and can just be remov= ed.) >=20 > 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. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)