Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20171114065731.3602-1-rakib.mullick@gmail.com>
References: <20171114065731.3602-1-rakib.mullick@gmail.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue, 14 Nov 2017 08:23:44 +0100
Message-ID: <CAKwiHFjKRioprSKnje1OJe_7u8mfWtjucLop7BZRE3sw4a83ZA@mail.gmail.com>
Subject: Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.
To:     Rakib Mullick <rakib.mullick@gmail.com>
Cc:     linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <mawilcox@microsoft.com>,
        Yury Norov <ynorov@caviumnetworks.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 14 November 2017 at 07:57, Rakib Mullick <rakib.mullick@gmail.com> wrote:
> Currently, during __bitmap_weight() calculation hweight_long() is used.
> Inside a hweight_long() a check has been made to figure out whether a
> hweight32() or hweight64() version to use.
>
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index d8f0c09..552096f 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -241,10 +241,15 @@ EXPORT_SYMBOL(__bitmap_subset);
>  int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
>  {
>         unsigned int k, lim = bits/BITS_PER_LONG;
> -       int w = 0;
> -
> -       for (k = 0; k < lim; k++)
> -               w += hweight_long(bitmap[k]);
> +       int w = 0, is32 = sizeof(bitmap[0]) ? 1 : 0;
> +

hint: sizeof() very rarely evaluates to zero... So this is the same as
"is32 = 1". So the patch as-is is broken (and may explain the 1-byte
delta in vmlinux). But even if this condition is fixed, the patch
doesn't change anything, since the sizeof() evaluation is done at
compile-time, regardless of whether it happens inside the inlined
hweight_long or outside. So it is certainly not worth it to duplicate
the loop.

Rasmus

From 1584269473230290707@xxx Fri Nov 17 00:05:06 +0000 2017
X-GM-THRID: 1584269473230290707
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread