[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080426.220726.13692428.davem@davemloft.net>
Date: Sat, 26 Apr 2008 22:07:26 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: linux-kernel@...r.kernel.org
CC: mingo@...e.hu, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, viro@...IV.linux.org.uk
Subject: find_new_bit bloat from x86 tree...
Ingo, what the heck is this?
commit 64970b68d2b3ed32b964b0b30b1b98518fde388e
Author: Alexander van Heukelum <heukelum@...lshack.com>
Date: Tue Mar 11 16:17:19 2008 +0100
x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
Thanks for bloating up the inline expansion of this thing on every
architecture that doesn't do __ffs() in a simple sequence of a few
instructions like x86 does.
Now every call that matches your tests gets this turd inline:
static inline unsigned long __ffs(unsigned long word)
{
int num = 0;
#if BITS_PER_LONG == 64
if ((word & 0xffffffff) == 0) {
num += 32;
word >>= 32;
}
#endif
if ((word & 0xffff) == 0) {
num += 16;
word >>= 16;
}
if ((word & 0xff) == 0) {
num += 8;
word >>= 8;
}
if ((word & 0xf) == 0) {
num += 4;
word >>= 4;
}
if ((word & 0x3) == 0) {
num += 2;
word >>= 2;
}
if ((word & 0x1) == 0)
num += 1;
return num;
}
as well as all of that address formation, bit shifting, and masking.
Please revert or make this conditional on something architectures can
opt-in for.
The version actually applied was posted only on linux-kernel, instead
of also CC:'ing linux-arch as previous versions had been. Nobody
commented on this version other than you Ingo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists