From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964970AbbBBM4e (ORCPT ); Mon, 2 Feb 2015 07:56:34 -0500 Received: from mail-la0-f48.google.com ([209.85.215.48]:65180 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964954AbbBBM4a (ORCPT ); Mon, 2 Feb 2015 07:56:30 -0500 From: Rasmus Villemoes To: "George Spelvin" Cc: yury.norov@gmail.com, 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, msalter@redhat.com, takahiro.akashi@linaro.org, tgraf@suug.ch, valentinrothberg@gmail.com, y.norov@samsung.com Subject: Re: [PATCH v2 1/3] lib: find_*_bit reimplementation Organization: D03 References: <878uggr3tm.fsf@rasmusvillemoes.dk> <20150202114759.25525.qmail@ns.horizon.com> X-Hashcash: 1:20:150202:y.norov@samsung.com::3jKJkULGXxzK4SZN:00000000000000000000000000000000000000000003P5 X-Hashcash: 1:20:150202:valentinrothberg@gmail.com::RQmXx92NW9CiygJD:0000000000000000000000000000000000004Ru X-Hashcash: 1:20:150202:laijs@cn.fujitsu.com::Q/fyVOiZphE6C+Ca:000000000000000000000000000000000000000000NHW X-Hashcash: 1:20:150202:akpm@linux-foundation.org::g1ExN+agquRXRYkX:00000000000000000000000000000000000020zc X-Hashcash: 1:20:150202:dborkman@redhat.com::GtFH3YZPIM3149vM:0000000000000000000000000000000000000000001yH0 X-Hashcash: 1:20:150202:davem@davemloft.net::ikXhc3KOByMR8768:0000000000000000000000000000000000000000002Pgg X-Hashcash: 1:20:150202:hannes@stressinduktion.org::t05bpIKAlUiAGccR:000000000000000000000000000000000002Zq5 X-Hashcash: 1:20:150202:yury.norov@gmail.com::uA8MkGChP95uWJGI:000000000000000000000000000000000000000004Dbl X-Hashcash: 1:20:150202:takahiro.akashi@linaro.org::rNd2i0ZQSD7ULbNh:000000000000000000000000000000000004i0I X-Hashcash: 1:20:150202:linux@horizon.com::kjKpXFEi0yOkYJjg:000000000000000000000000000000000000000000005Rmf X-Hashcash: 1:20:150202:linux-kernel@vger.kernel.org::hqbmsP4Mj0vsvzmN:0000000000000000000000000000000007mQ9 X-Hashcash: 1:20:150202:chris@chris-wilson.co.uk::PCX/MwsTgjv0IdBR:00000000000000000000000000000000000008bea X-Hashcash: 1:20:150202:tgraf@suug.ch::VPsnN2L+0+sZwNGZ:00009LiP X-Hashcash: 1:20:150202:klimov.linux@gmail.com::CEeLCwz7nz/9t+T2:000000000000000000000000000000000000000ISpu X-Hashcash: 1:20:150202:msalter@redhat.com::M0Evl132EV5K5CxQ:0000000000000000000000000000000000000000000Pekm Date: Mon, 02 Feb 2015 13:56:27 +0100 In-Reply-To: <20150202114759.25525.qmail@ns.horizon.com> (George Spelvin's message of "2 Feb 2015 06:47:59 -0500") Message-ID: <87twz4pj44.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 02 2015, "George Spelvin" wrote: > 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. Nice trick. When I compiled it, gcc inlined _find_next_bit into both its callers, making the conditional go away completely. That was with gcc 4.7. When I try with 5.0, I do see _find_next_bit being compiled separately. With the proposed change, 4.7 also makes find_next{,_zero}_bit wrappers for _find_next_bit, further reducing the total size, which is a good thing. And, if some other version decides to still inline it, it should then know how to optimize the xor with 0ul or ~0ul just as well as when the conditional was folded away. Yury, please also incorporate this in the next round. Rasmus