From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, 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>
Subject: Re: [PATCH 0/5] use abstracted bit count functions
Date: Thu, 2 Nov 2023 08:27:37 -0700 [thread overview]
Message-ID: <20231102152737.GA27149@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFC6@smartserver.smartshare.dk>
On Thu, Nov 02, 2023 at 08:39:04AM +0100, Morten Brørup 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.
they haven't been blindly replaced. but i would like you to validate my
thinking.
in the case of counting trailing 0s it seems fine if the type is
promoted to 64-bits, in the case of leading i checked the type to make
sure it was already operating on a 64-bit type.
too naive?
next prev parent reply other threads:[~2023-11-02 15:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-02 1:05 Tyler Retzlaff
2023-11-02 1:05 ` [PATCH 1/5] table: " Tyler Retzlaff
2023-11-02 1:05 ` [PATCH 2/5] distributor: " Tyler Retzlaff
2023-11-02 1:05 ` [PATCH 3/5] hash: " Tyler Retzlaff
2023-11-02 1:05 ` [PATCH 4/5] member: " Tyler Retzlaff
2023-11-02 1:05 ` [PATCH 5/5] rcu: " Tyler Retzlaff
2023-11-02 7:39 ` [PATCH 0/5] " Morten Brørup
2023-11-02 15:27 ` Tyler Retzlaff [this message]
2023-11-02 15:33 ` Morten Brørup
2023-11-02 15:36 ` Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 " Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 1/5] distributor: " Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 2/5] hash: " Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 3/5] member: " Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 4/5] rcu: " Tyler Retzlaff
2023-11-07 19:10 ` [PATCH v2 5/5] table: " Tyler Retzlaff
2023-11-08 8:25 ` [PATCH v2 0/5] " Morten Brørup
2023-11-07 23:38 ` [PATCH v3 0/7] " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 1/7] distributor: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 2/7] hash: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 3/7] member: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 4/7] rcu: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 5/7] table: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 6/7] distributor: " Tyler Retzlaff
2023-11-07 23:38 ` [PATCH v3 7/7] hash: " Tyler Retzlaff
2023-11-08 8:47 ` CI test system not catching truncation bugs for 32-bit architectures? Morten Brørup
2023-11-08 8:34 ` [PATCH v3 0/7] use abstracted bit count functions Morten Brørup
2023-11-08 16:57 ` Thomas Monjalon
2023-11-08 18:42 ` Tyler Retzlaff
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=20231102152737.GA27149@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=roretzla@linux.microsoft.com \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=mb@smartsharesystems.com \
--cc=ruifeng.wang@arm.com \
--cc=sameh.gobriel@intel.com \
--cc=vladimir.medvedkin@intel.com \
--cc=yipeng1.wang@intel.com \
/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).