[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLabOHmNQm2EOXWR@smile.fi.intel.com>
Date: Tue, 18 Jul 2023 17:01:28 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: Yury Norov <yury.norov@...il.com>, catalin.marinas@....com,
will@...nel.org, pcc@...gle.com, andreyknvl@...il.com,
linux@...musvillemoes.dk, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com,
syednwaris@...il.com, william.gray@...aro.org,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3 1/5] lib/bitmap: add bitmap_{set,get}_value()
On Tue, Jul 18, 2023 at 11:30:00AM +0200, Alexander Potapenko wrote:
> On Mon, Jul 17, 2023 at 5:51 PM Yury Norov <yury.norov@...il.com> wrote:
> > On Mon, Jul 17, 2023 at 01:37:04PM +0200, Alexander Potapenko wrote:
...
> > When nbits == 0, copy-like functions shouldn't touch any memory. See how
> > other bitmap and find_bit functions hold it.
>
> I think this is different from what other bitmap functions do, but it
> should be enough to bail out on !nbits, i.e.:
>
> if (!nbits)
> return 0;
>
> You probably meant adding a __builtin_constant_p() (which is used all
> over the place in bitmap.h), but:
> - the compiler won't have problem optimizing away the code for a
> constant nbits=0;
> - we anyway need a dynamic check for the case nbits is not constant
> (for both bitmap_get_value() and bitmap_set_value(), I assume).
>
> What do you think?
The idea behind is to eliminate the code completely for the cases nbits != 0.
In your case the dynamic check will be there. That's what we want to avoid.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists