From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id BD5994326B;
	Thu,  2 Nov 2023 08:39:11 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id A05684029E;
	Thu,  2 Nov 2023 08:39:11 +0100 (CET)
Received: from dkmailrelay1.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id 457E840282
 for <dev@dpdk.org>; Thu,  2 Nov 2023 08:39:10 +0100 (CET)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesys.local [192.168.4.10])
 by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 169D821AB0;
 Thu,  2 Nov 2023 08:39:10 +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 08:39:04 +0100
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFC6@smartserver.smartshare.dk>
In-Reply-To: <1698887132-5347-1-git-send-email-roretzla@linux.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PATCH 0/5] use abstracted bit count functions
Thread-Index: AdoNKLpi1Zv20terRkehlPJU+15QDAANFeSg
References: <1698887132-5347-1-git-send-email-roretzla@linux.microsoft.com>
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	<dev@dpdk.org>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>,
 "Cristian Dumitrescu" <cristian.dumitrescu@intel.com>,
 "David Hunt" <david.hunt@intel.com>,
 "Honnappa Nagarahalli" <honnappa.nagarahalli@arm.com>,
 "Ruifeng Wang" <ruifeng.wang@arm.com>,
 "Sameh Gobriel" <sameh.gobriel@intel.com>,
 "Vladimir Medvedkin" <vladimir.medvedkin@intel.com>,
 "Yipeng Wang" <yipeng1.wang@intel.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Thursday, 2 November 2023 02.05
>=20
> 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.