[PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()

Andrew Cooper posted 9 patches 3 months ago
There is a newer version of this series
[PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()
Posted by Andrew Cooper 3 months ago
They are no more, and won't be returning in this form.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 xen/arch/arm/include/asm/bitops.h |  2 --
 xen/arch/ppc/include/asm/bitops.h |  2 --
 xen/arch/x86/include/asm/bitops.h |  2 --
 xen/include/xen/bitops.h          | 17 -----------------
 4 files changed, 23 deletions(-)

diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h
index 3c023103f734..91cd167b6bbb 100644
--- a/xen/arch/arm/include/asm/bitops.h
+++ b/xen/arch/arm/include/asm/bitops.h
@@ -86,8 +86,6 @@ bool clear_mask16_timeout(uint16_t mask, volatile void *p,
  */
 #define hweight64(x) generic_hweight64(x)
 #define hweight32(x) generic_hweight32(x)
-#define hweight16(x) generic_hweight16(x)
-#define hweight8(x) generic_hweight8(x)
 
 #endif /* _ARM_BITOPS_H */
 /*
diff --git a/xen/arch/ppc/include/asm/bitops.h b/xen/arch/ppc/include/asm/bitops.h
index eb3355812ea3..a62c4f99c3bb 100644
--- a/xen/arch/ppc/include/asm/bitops.h
+++ b/xen/arch/ppc/include/asm/bitops.h
@@ -132,7 +132,5 @@ static inline int test_and_set_bit(unsigned int nr, volatile void *addr)
  */
 #define hweight64(x) __builtin_popcountll(x)
 #define hweight32(x) __builtin_popcount(x)
-#define hweight16(x) __builtin_popcount((uint16_t)(x))
-#define hweight8(x)  __builtin_popcount((uint8_t)(x))
 
 #endif /* _ASM_PPC_BITOPS_H */
diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h
index 8c0403405aa2..4c5b21907a64 100644
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -483,7 +483,5 @@ static always_inline unsigned int arch_flsl(unsigned long x)
  */
 #define hweight64(x) generic_hweight64(x)
 #define hweight32(x) generic_hweight32(x)
-#define hweight16(x) generic_hweight16(x)
-#define hweight8(x) generic_hweight8(x)
 
 #endif /* _X86_BITOPS_H */
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 74c0d04e6647..64d70a7a1cb5 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -371,23 +371,6 @@ static inline unsigned int generic_hweight32(unsigned int w)
     return (w + (w >> 16)) & 0xff;
 }
 
-static inline unsigned int generic_hweight16(unsigned int w)
-{
-    w -= ((w >> 1) & 0x5555);
-    w =  (w & 0x3333) + ((w >> 2) & 0x3333);
-    w =  (w + (w >> 4)) & 0x0f0f;
-
-    return (w + (w >> 8)) & 0xff;
-}
-
-static inline unsigned int generic_hweight8(unsigned int w)
-{
-    w -= ((w >> 1) & 0x55);
-    w =  (w & 0x33) + ((w >> 2) & 0x33);
-
-    return (w + (w >> 4)) & 0x0f;
-}
-
 static inline unsigned int generic_hweight64(uint64_t w)
 {
     if ( BITS_PER_LONG < 64 )
-- 
2.39.2


Re: [PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()
Posted by Jan Beulich 2 months, 4 weeks ago
On 23.08.2024 01:06, Andrew Cooper wrote:
> They are no more, and won't be returning in this form.

And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
Not overly nice I would say.

Jan
Re: [PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()
Posted by Andrew Cooper 2 months, 4 weeks ago
On 26/08/2024 11:39 am, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> They are no more, and won't be returning in this form.
> And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
> Not overly nice I would say.

If we ever regain a genuine need for the 8 or 16 forms, they can go back
into bitops.h, in terms of hweightl(), just like hweight32().

But it's been 20 years so far and we haven't actually needed
hweight8/16, and I'm expecting this to continue for the forseeable future.

~Andrew
Re: [PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()
Posted by Jan Beulich 2 months, 4 weeks ago
On 27.08.2024 11:49, Andrew Cooper wrote:
> On 26/08/2024 11:39 am, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> They are no more, and won't be returning in this form.
>> And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
>> Not overly nice I would say.
> 
> If we ever regain a genuine need for the 8 or 16 forms, they can go back
> into bitops.h, in terms of hweightl(), just like hweight32().
> 
> But it's been 20 years so far and we haven't actually needed
> hweight8/16, and I'm expecting this to continue for the forseeable future.

Well, I'm not fully convinced. People may (try to) add open-coded forms like
in my earlier reply instead. But anyway:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan
Re: [PATCH 4/9] xen/bitops: Drop the remnants of hweight{8,16}()
Posted by Andrew Cooper 2 months, 4 weeks ago
On 27/08/2024 11:11 am, Jan Beulich wrote:
> On 27.08.2024 11:49, Andrew Cooper wrote:
>> On 26/08/2024 11:39 am, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>>> They are no more, and won't be returning in this form.
>>> And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
>>> Not overly nice I would say.
>> If we ever regain a genuine need for the 8 or 16 forms, they can go back
>> into bitops.h, in terms of hweightl(), just like hweight32().
>>
>> But it's been 20 years so far and we haven't actually needed
>> hweight8/16, and I'm expecting this to continue for the forseeable future.
> Well, I'm not fully convinced. People may (try to) add open-coded forms like
> in my earlier reply instead.

I'd hope we'd spot that during review, and even if not, we can fix it up
after the fact.

>  But anyway:
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

~Andrew