All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury <yury.norov@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	George Spelvin <linux@horizon.com>
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,
	msalter@redhat.com, takahiro.akashi@linaro.org, tgraf@suug.ch,
	valentinrothberg@gmail.com, Yury Norov <y.norov@samsung.com>
Subject: Re: [PATCH v2 1/3] lib: find_*_bit reimplementation
Date: Thu, 05 Feb 2015 02:45:18 +0300	[thread overview]
Message-ID: <54D2AF0E.30500@gmail.com> (raw)
In-Reply-To: <87twz4pj44.fsf@rasmusvillemoes.dk>


On 02.02.2015 15:56, Rasmus Villemoes wrote:
> On Mon, Feb 02 2015, "George Spelvin" <linux@horizon.com> wrote:
>
>> Rasmus Villemoes <linux@rasmusvillemoes.dk> 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
>
Ok.
What are you thinking about joining _find_next_bit and _find_next_bit_le?
They really differ in 2 lines.  It's generally good to remove duplications,
and it may decrease text size for big-endian machines. But it definitely
doesn't make code easier for reading, and maybe affects performance
after the optimization suggested by George...

(I didn't test it yet)

 29 #if !defined(find_next_bit) || !defined(find_next_zero_bit) \
 30         || (defined(BIG_ENDIAN) && \
 31                 (!defined(find_next_bit_le) || !defined(find_next_zero_bit_le)))
 32 static unsigned long _find_next_bit(const unsigned long *addr,
 33                 unsigned long nbits, unsigned long start, unsigned long flags)
 34 {
 35         unsigned long xor_mask = (flags & SET) ? 0UL : ULONG_MAX;
 36         unsigned long tmp = addr[start / BITS_PER_LONG] ^ xor_mask;
 37 
 38         /* Handle 1st word. */
 39         if (!IS_ALIGNED(start, BITS_PER_LONG)) {
 40 #ifdef BIG_ENDIAN
 41                 if (flags & LE)
 42                         tmp &= ext2_swab(HIGH_BITS_MASK(start % BITS_PER_LONG));
 43                 else
 44 #endif
 45                         tmp &= HIGH_BITS_MASK(start % BITS_PER_LONG);
 46 
 47                 start = round_down(start, BITS_PER_LONG);
 48         }
 49 
 50         while (!tmp) {
 51                 start += BITS_PER_LONG;
 52                 if (start >= nbits)
 53                         return nbits;
 54 
 55                 tmp = addr[start / BITS_PER_LONG] ^ xor_mask;
 56         }
 57 
 58 #ifdef BIG_ENDIAN
 59         if (flags & LE)
 60                 return start + __ffs(ext2_swab(tmp));
 61 
 62 #endif
 63         return start + __ffs(tmp);
 64 }
 65 #endif



  reply	other threads:[~2015-02-04 23:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31 20:58 [PATCH v2 1/3] lib: find_*_bit reimplementation yury.norov
2015-01-31 20:58 ` [PATCH v2 2/3] lib: move find_last_bit to lib/find_next_bit.c yury.norov
2015-01-31 20:58 ` [PATCH v2 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c yury.norov
2015-02-02 11:09   ` Rasmus Villemoes
2015-02-02  3:17 ` [PATCH v2 1/3] lib: find_*_bit reimplementation George Spelvin
2015-02-04 23:07   ` Yury
2015-02-02 10:43 ` Rasmus Villemoes
2015-02-02 11:47   ` George Spelvin
2015-02-02 12:56     ` Rasmus Villemoes
2015-02-04 23:45       ` Yury [this message]
2015-02-05 14:51         ` Rasmus Villemoes
2015-02-04 22:52   ` Yury
2015-02-05 15:01     ` Rasmus Villemoes
  -- strict thread matches above, loose matches on Subject: below --
2015-02-05 23:07 Alexey Klimov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D2AF0E.30500@gmail.com \
    --to=yury.norov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=hannes@stressinduktion.org \
    --cc=klimov.linux@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=linux@rasmusvillemoes.dk \
    --cc=msalter@redhat.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tgraf@suug.ch \
    --cc=valentinrothberg@gmail.com \
    --cc=y.norov@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.