From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F41B1C433DB for ; Mon, 1 Feb 2021 13:51:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC56B64D9D for ; Mon, 1 Feb 2021 13:51:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231422AbhBANvQ (ORCPT ); Mon, 1 Feb 2021 08:51:16 -0500 Received: from mga02.intel.com ([134.134.136.20]:48566 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231259AbhBANvP (ORCPT ); Mon, 1 Feb 2021 08:51:15 -0500 IronPort-SDR: +BoOSAD8kFnmhW92MvmSBLCCYbLFzNmd6+JyCUA2mMx/NdsJ+cMZ+JdJQJid+ZpJoMMIzafRqv l+mtH9D4FgBA== X-IronPort-AV: E=McAfee;i="6000,8403,9881"; a="167789228" X-IronPort-AV: E=Sophos;i="5.79,392,1602572400"; d="scan'208";a="167789228" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2021 05:49:27 -0800 IronPort-SDR: HIGuIYqfme9l0ZvuvTAb7RogaVsqKQpkOy5QozRDhot1puv9UHMLoRNWbb9P1A9eMYYk76lJ7K EHlSloz2I1Vg== X-IronPort-AV: E=Sophos;i="5.79,392,1602572400"; d="scan'208";a="577834479" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2021 05:49:23 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1l6ZZv-0018zx-1X; Mon, 01 Feb 2021 15:49:19 +0200 Date: Mon, 1 Feb 2021 15:49:19 +0200 From: Andy Shevchenko To: Yury Norov Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, linux-arch@vger.kernel.org, Geert Uytterhoeven , Yoshinori Sato , Rich Felker , Arnd Bergmann , Dennis Zhou , Andrew Morton , Wolfram Sang , David Sterba , Stefano Brivio , "Ma, Jianpeng" , Wei Yang , Josh Poimboeuf , John Paul Adrian Glaubitz , Joe Perches Subject: Re: [PATCH 7/8] lib: add fast path for find_next_*_bit() Message-ID: References: <20210130191719.7085-1-yury.norov@gmail.com> <20210130191719.7085-8-yury.norov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210130191719.7085-8-yury.norov@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On Sat, Jan 30, 2021 at 11:17:18AM -0800, Yury Norov wrote: > Similarly to bitmap functions, find_next_*_bit() users will benefit > if we'll handle a case of bitmaps that fit into a single word. In the > very best case, the compiler may replace a function call with a > single ffs or ffz instruction. Would be nice to have the examples how it reduces the actual code size (based on the existing code in kernel, especially in widely used frameworks / subsystems, like PCI). -- With Best Regards, Andy Shevchenko