Re: [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size [try #3]

[David Howells <dhowells@redhat.com>]

> > > What's the attribute((pure)) for?
> >
> > It tells gcc that the function's result only depends on its arguments... it
> > makes no references at all to external data. It's like __attribute__((const))
> > but stronger. This means that gcc can generate code that caches the result.

Actually... I'm wrong about that. I've got "pure" and "const" the wrong way
around... Perhaps I need to go and read the gcc manual too:-)

> Of course, but we could use it in zillions of places and we don't.  Does it
> actually help?

Well... it could. It certainly doesn't hurt. Actually, it's probably
irrelevant on inline functions as the compiler can look inside of those.

> > > The other four or five implementations of log2() use ffx(~n).
> >

I presume this should be ffz() not ffx().

> > Yes... but ffs() and ffz() take int args, not long args. I suspect that
> > shouldn't matter (that would require the hash table to be calculated at 4Gig
> > buckets in size or greater to be a problem), but why take the chance when we
> > can avoid it easily?
>
> No, ffz() takes an unsigned long argument.

So it does. However, ffz(~n) is not equivalent to log2(n). This can be
demonstrated by this little test program:

	#include <stdio.h>
	#include <stdlib.h>

	static __inline__ unsigned long ffz(unsigned long word)
	{
		__asm__("bsfl %1,%0"
			:"=r" (word)
			:"r" (~word));
		return word;
	}

	int main(int argc, char *argv[])
	{
		for (argv++; *argv; argv++)
			printf("%lu\n", ffz(~strtoul(*argv, NULL, 0)));

		return 0;
	}

	dhowells>/tmp/ffz 0x10
	4
	dhowells>/tmp/ffz 0x8
	3
	dhowells>/tmp/ffz 0x1f
	0

This is not entirely correct; the third answer should be 4 too. The bit scan
occurs in the wrong direction.

David