From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 42F5343270; Thu, 2 Nov 2023 16:34:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9D1840262; Thu, 2 Nov 2023 16:34:01 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 56B3740144 for ; Thu, 2 Nov 2023 16:34:00 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 1AC20208A2; Thu, 2 Nov 2023 16:34:00 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH 0/5] use abstracted bit count functions X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 2 Nov 2023 16:33:57 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFCA@smartserver.smartshare.dk> In-Reply-To: <20231102152737.GA27149@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 0/5] use abstracted bit count functions Thread-Index: AdoNoR6BxSBFsmWBSAmYAhZlL1W+FgAACJgw References: <1698887132-5347-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35E9EFC6@smartserver.smartshare.dk> <20231102152737.GA27149@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" Cc: , "Bruce Richardson" , "Cristian Dumitrescu" , "David Hunt" , "Honnappa Nagarahalli" , "Ruifeng Wang" , "Sameh Gobriel" , "Vladimir Medvedkin" , "Yipeng Wang" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Thursday, 2 November 2023 16.28 >=20 > On Thu, Nov 02, 2023 at 08:39:04AM +0100, Morten Br=F8rup wrote: > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > Sent: Thursday, 2 November 2023 02.05 > > > > > > The first set of conversions missed the long 'l' versions of the > > > builtins that were being used. This series completes the = conversion > > > of remaining libraries from __builtin_ctzl and __builtin_clzl. > > > > NAK to blind search/replace of __builtin_clzl()/clzl(). > > > > Although the size of long is 64 bit on 64 bit architectures, it only > 32 bit on 32 bit architectures. > > > > You need to look at the types these builtins operate on: > > - E.g. in the hash library (patch 3/5) = prim_hitmask[i]/sec_hitmask[i] > are uint32_t, so rte_ctz32() would be the correct replacement. (I am > now asking myself why they were using __builtin_ctzl() instead of > __builtin_ctz() here... Probably by mistake.) > > - And if the type is "long", you need conditional compiling (or a > wrapper macro) to choose between the 32 bit or 64 bit variants. > > > > NB: You can blindly replace __builtin_ctzll()/clzll(), if any, by 64 > bit functions. >=20 > they haven't been blindly replaced. but i would like you to validate = my > thinking. >=20 > in the case of counting trailing 0s it seems fine if the type is > promoted to 64-bits, This will give the correct result, yes. However the 64-bit operation = might have a higher performance cost than the 32-bit operation, = especially on 32-bit architectures. > in the case of leading i checked the type to make > sure it was already operating on a 64-bit type. If already operating on a 64-bit type, using the 64-bit function is = obviously correct. >=20 > too naive?