[lkml]   [2008]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86: generic versions of find_first_(zero_)bit, convert i386

* Alexander van Heukelum <> wrote:

> Generic versions of __find_first_bit and __find_first_zero_bit are
> introduced as simplified versions of __find_next_bit and
> __find_next_zero_bit. Their compilation and use are guarded by a new
> config variable GENERIC_FIND_FIRST_BIT.
> The generic versions of find_first_bit and find_first_zero_bit are
> implemented in terms of the newly introduced __find_first_bit and
> __find_first_zero_bit.
> This patch also converts i386 to the generic functions. The text size
> shrinks slightly due to uninlining of the find_*_bit functions.
> text data bss dec hex filename
> 4764939 480324 622592 5867855 59894f vmlinux (i386 defconfig before)
> 4764645 480324 622592 5867561 598829 vmlinux (i386 defconfig after)
> Signed-off-by: Alexander van Heukelum <>
> ---
> Hi Ingo,
> Here is another step in the unification of the bitops for i386 and
> x86_64. This patch implements a minimal conversion to a generic
> implementation of find_first_bit/find_first_zero_bit for i386. The
> optimization for small bitmaps and the conversion of x86_64 will
> follow soon.
> Compiles and runs fine on i386 and x86_64 (current x86#testing).

thanks, applied.

I guess we should keep the bitops.h portions alive for the moment though
(surrounded by #ifndef GENERIC_FIND_FIRST_BIT), to make it easy for
anyone to flip the Kconfig bit around via a oneliner patch and do some
benchmarking? At least initially - i'm convinced that we want the
generic versions in the long run. (especially if, as your patches do it,
the generic code picks up the easy constant tests and optimizes them at
build time)


 \ /
  Last update: 2008-04-01 10:49    [W:0.098 / U:0.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site