On Mon, May 17, 2010 at 17:21, Ingo Molnar wrote:
> arch/alpha/include/asm/bitops.h | 18 +++++----
> arch/ia64/include/asm/bitops.h | 11 +++--
> arch/sparc/include/asm/bitops_64.h | 11 +++--
> arch/x86/include/asm/bitops.h | 4 +-
> include/asm-generic/bitops/arch_hweight.h | 25 ++++++++++++
> include/asm-generic/bitops/const_hweight.h | 42 ++++++++++++++++++++
> include/asm-generic/bitops/hweight.h | 8 +---
did this miss Blackfin because the original patch was against the
2.6.34 tree ? just wondering why it now build fails ...
doing a simple grep shows that the new "tile" arch may also be broken
as it uses "hweight32" ...
considering __sw_hweightX only exist when the generic hweight is in
play, wouldnt it make sense to have
include/asm-generic/bitops/arch_hweight.h not always define things ?
then most arches can simply pull in
include/asm-generic/bitops/hweight.h without having to worry about the
random inner details of hweight cruft.
diff --git a/include/asm-generic/bitops/arch_hweight.h
b/include/asm-generic/bitops/arch_hweight.h
index 6a211f4..3a62e38 100644
--- a/include/asm-generic/bitops/arch_hweight.h
+++ b/include/asm-generic/bitops/arch_hweight.h
@@ -1,8 +1,15 @@
#ifndef _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
#define _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
+#ifdef CONFIG_GENERIC_HWEIGHT
+
#include <asm/types.h>
+extern unsigned int __sw_hweight8(unsigned int w);
+extern unsigned int __sw_hweight16(unsigned int w);
+extern unsigned int __sw_hweight32(unsigned int w);
+extern unsigned long __sw_hweight64(__u64 w);
+
static inline unsigned int __arch_hweight32(unsigned int w)
{
return __sw_hweight32(w);
@@ -22,4 +29,7 @@ static inline unsigned long __arch_hweight64(__u64 w)
{
return __sw_hweight64(w);
}
+
+#endif /* CONFIG_GENERIC_HWEIGHT */
+
#endif /* _ASM_GENERIC_BITOPS_HWEIGHT_H_ */
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index fc68053..2e58012 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -10,11 +10,6 @@
#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
#endif
-extern unsigned int __sw_hweight8(unsigned int w);
-extern unsigned int __sw_hweight16(unsigned int w);
-extern unsigned int __sw_hweight32(unsigned int w);
-extern unsigned long __sw_hweight64(__u64 w);
-
/*
* Include this here because some architectures need generic_ffs/fls in
* scope
-mike
On 08/13/2010 02:42 PM, Mike Frysinger wrote:
> On Mon, May 17, 2010 at 17:21, Ingo Molnar wrote:
>> arch/alpha/include/asm/bitops.h | 18 +++++----
>> arch/ia64/include/asm/bitops.h | 11 +++--
>> arch/sparc/include/asm/bitops_64.h | 11 +++--
>> arch/x86/include/asm/bitops.h | 4 +-
>> include/asm-generic/bitops/arch_hweight.h | 25 ++++++++++++
>> include/asm-generic/bitops/const_hweight.h | 42 ++++++++++++++++++++
>> include/asm-generic/bitops/hweight.h | 8 +---
>
> did this miss Blackfin because the original patch was against the
> 2.6.34 tree ? just wondering why it now build fails ...
>
> doing a simple grep shows that the new "tile" arch may also be broken
> as it uses "hweight32" ...
>
> considering __sw_hweightX only exist when the generic hweight is in
> play, wouldnt it make sense to have
> include/asm-generic/bitops/arch_hweight.h not always define things ?
> then most arches can simply pull in
> include/asm-generic/bitops/hweight.h without having to worry about the
> random inner details of hweight cruft.
>
__sw_hweightX can exist even when generic hweight isn't in use per se,
because the arch implementation can wrapper the software implementation.
This is the case on x86, for example -- most x86 CPUs don't have popcnt
yet, so on those the x86 implementation end up calling the
__sw_hweight*() implementations.
-hpa
On Fri, Aug 13, 2010 at 17:56, H. Peter Anvin wrote:
> On 08/13/2010 02:42 PM, Mike Frysinger wrote:
>> On Mon, May 17, 2010 at 17:21, Ingo Molnar wrote:
>>> arch/alpha/include/asm/bitops.h | 18 +++++----
>>> arch/ia64/include/asm/bitops.h | 11 +++--
>>> arch/sparc/include/asm/bitops_64.h | 11 +++--
>>> arch/x86/include/asm/bitops.h | 4 +-
>>> include/asm-generic/bitops/arch_hweight.h | 25 ++++++++++++
>>> include/asm-generic/bitops/const_hweight.h | 42 ++++++++++++++++++++
>>> include/asm-generic/bitops/hweight.h | 8 +---
>>
>> did this miss Blackfin because the original patch was against the
>> 2.6.34 tree ? just wondering why it now build fails ...
>>
>> doing a simple grep shows that the new "tile" arch may also be broken
>> as it uses "hweight32" ...
>>
>> considering __sw_hweightX only exist when the generic hweight is in
>> play, wouldnt it make sense to have
>> include/asm-generic/bitops/arch_hweight.h not always define things ?
>> then most arches can simply pull in
>> include/asm-generic/bitops/hweight.h without having to worry about the
>> random inner details of hweight cruft.
>>
>
> __sw_hweightX can exist even when generic hweight isn't in use per se,
> because the arch implementation can wrapper the software implementation.
> This is the case on x86, for example -- most x86 CPUs don't have popcnt
> yet, so on those the x86 implementation end up calling the
> __sw_hweight*() implementations.
but those targets still define CONFIG_GENERIC_HWEIGHT right ? so at
the least, we should be wrapping the prototypes in linux/bitops.h with
that ...
-mike
On 08/13/2010 02:59 PM, Mike Frysinger wrote:
>
> but those targets still define CONFIG_GENERIC_HWEIGHT right ? so at
> the least, we should be wrapping the prototypes in linux/bitops.h with
> that ...
>
Yes, I guess they do.
-hpa
See commit 1527bc8b928dd1399c3d3467dd47d9ede210978a.
Signed-off-by: Chris Metcalf <[email protected]>
---
Mike, thanks for the pointer to the hweight issue. Since we are using
__builtin_popcount() and the compiler can do constant propagation, etc.,
with it at compile-time, this is less critical, but it seems like the
easiest way to get the definitions of the HWEIGHT macros.
arch/tile/include/asm/bitops.h | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/tile/include/asm/bitops.h b/arch/tile/include/asm/bitops.h
index 84600f3..6832b4b 100644
--- a/arch/tile/include/asm/bitops.h
+++ b/arch/tile/include/asm/bitops.h
@@ -98,26 +98,27 @@ static inline int fls64(__u64 w)
return (sizeof(__u64) * 8) - __builtin_clzll(w);
}
-static inline unsigned int hweight32(unsigned int w)
+static inline unsigned int __arch_hweight32(unsigned int w)
{
return __builtin_popcount(w);
}
-static inline unsigned int hweight16(unsigned int w)
+static inline unsigned int __arch_hweight16(unsigned int w)
{
return __builtin_popcount(w & 0xffff);
}
-static inline unsigned int hweight8(unsigned int w)
+static inline unsigned int __arch_hweight8(unsigned int w)
{
return __builtin_popcount(w & 0xff);
}
-static inline unsigned long hweight64(__u64 w)
+static inline unsigned long __arch_hweight64(__u64 w)
{
return __builtin_popcountll(w);
}
+#include <asm-generic/bitops/const_hweight.h>
#include <asm-generic/bitops/lock.h>
#include <asm-generic/bitops/sched.h>
#include <asm-generic/bitops/ext2-non-atomic.h>
--
1.6.5.2
On Fri, Aug 13, 2010 at 20:32, Chris Metcalf wrote:
> Mike, thanks for the pointer to the hweight issue. Since we are using
> __builtin_popcount() and the compiler can do constant propagation, etc.,
> with it at compile-time, this is less critical, but it seems like the
> easiest way to get the definitions of the HWEIGHT macros.
interesting ... i wasnt aware of the popcount builtin. the Blackfin
ISA has a "ONES" insn which does this. guess we should implement the
popcount builtin too.
-mike
From: "H. Peter Anvin" <[email protected]>
Date: Fri, Aug 13, 2010 at 05:11:14PM -0700
> On 08/13/2010 02:59 PM, Mike Frysinger wrote:
> >
> > but those targets still define CONFIG_GENERIC_HWEIGHT right ? so at
> > the least, we should be wrapping the prototypes in linux/bitops.h with
> > that ...
> >
>
> Yes, I guess they do.
Actually, Mike's issue is valid, if I understand it correctly. From
looking at <arch/blackfin/include/asm/bitops.h>, Blackfin doesn't need
the generic software variants __sw_hweightXX at all, right?
In that case, <include/linux/bitops.h> is pulling in needlessly
unresolved symbols for arches which have their hw versions of
hweight and don't need sw variants. However, if you want to include
<asm-generic/bitops/hweight.h> and benefit from the compile-time
evaluation of the const hweight args, you're going to need to rename
the hweightXX() functions in <arch/blackfin/include/asm/bitops.h> to
__arch_hweightXX but that shouldn't be a problem I guess :).
Let me give your patch from couple of mails ago a quick spin...
--
Regards/Gruss,
Boris.