From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60234)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Wxuep-0004iT-Sy
	for qemu-devel@nongnu.org; Fri, 20 Jun 2014 04:58:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Wxuej-00006O-Nw
	for qemu-devel@nongnu.org; Fri, 20 Jun 2014 04:58:51 -0400
Received: from mx1.redhat.com ([209.132.183.28]:50860)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Wxuej-00006I-Fu
	for qemu-devel@nongnu.org; Fri, 20 Jun 2014 04:58:45 -0400
Message-ID: <53A3F7B7.2030206@redhat.com>
Date: Fri, 20 Jun 2014 10:58:31 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1387711957-703-1-git-send-email-aurelien@aurel32.net>
	<53A2A102.4060807@redhat.com> <20140620084806.GB13901@ohm.rr44.fr>
In-Reply-To: <20140620084806.GB13901@ohm.rr44.fr>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] bitops: provide an inline implementation
	of find_first_bit
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org, Corentin Chary <corentin.chary@gmail.com>, Richard Henderson <rth@twiddle.net>

Il 20/06/2014 10:48, Aurelien Jarno ha scritto:
> In practice on x86_64, this function takes 27 instructions in the
> general case, and 18 instructions in the fixed case, even for big
> sizes. I therefore think that checking if the size is constant is a good
> idea, but we should not make any test on the size itself and trust the
> compiler to correctly decide if the loop should be unrolled or not.

But if the size is large enough that the compiler will (likely) not 
unroll the function, then it should pay off to use the more optimized 
code in find_next_bit.

This of course is unless you expect find_first_bit to return a small 
value and not be used in a loop; and dually expect find_next_bit's usage 
to be more like walking sparser bitmaps in a loop.

This actually makes sense, and then there's no need to change anything.

Paolo