From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755225AbbBBLsF (ORCPT ); Mon, 2 Feb 2015 06:48:05 -0500 Received: from ns.horizon.com ([71.41.210.147]:57215 "HELO ns.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751890AbbBBLsB (ORCPT ); Mon, 2 Feb 2015 06:48:01 -0500 Date: 2 Feb 2015 06:47:59 -0500 Message-ID: <20150202114759.25525.qmail@ns.horizon.com> From: "George Spelvin" To: linux@rasmusvillemoes.dk, yury.norov@gmail.com Subject: Re: [PATCH v2 1/3] lib: find_*_bit reimplementation Cc: akpm@linux-foundation.org, chris@chris-wilson.co.uk, davem@davemloft.net, dborkman@redhat.com, hannes@stressinduktion.org, klimov.linux@gmail.com, laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org, linux@horizon.com, msalter@redhat.com, takahiro.akashi@linaro.org, tgraf@suug.ch, valentinrothberg@gmail.com, y.norov@samsung.com In-Reply-To: <878uggr3tm.fsf@rasmusvillemoes.dk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rasmus Villemoes wrote: > ... and this be part of _find_next_bit? Can find_next_bit not be simply > 'return _find_next_bit(addr, size, offset, 1);', and similarly for > find_next_zero_bit? Btw., passing true and false for the boolean > parameter may be a little clearer. Looking at the generated code, it would be better to replace the boolean parameter with 0ul or ~0ul and XOR with it. The same number of registers, and saves a conditional branch. (I was hoping GCC would figure that trick out, but it didn't.)