Messages in this thread | | | From | Andy Shevchenko <> | Date | Thu, 8 Jun 2017 17:47:09 +0300 | Subject | Re: [PATCH 3/3] bitmap: Use memcmp optimisation in more situations |
| |
On Thu, Jun 8, 2017 at 4:43 PM, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > On 8 June 2017 at 14:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >> On Thu, Jun 8, 2017 at 5:55 AM, Matthew Wilcox <willy@infradead.org> wrote: >>> We only need to know if the bottom 3 bits are 0 to apply this optimisation. >>> For example, if we have a user which does this: >>> >>> nbits = 8; >>> if (argle) >>> nbits += 8; >>> if (bitmap_equal(ptr1, ptr2, nbits)) >>> blah(); >>> >>> then we can use memcmp() because gcc can deduce that the bottom 3 bits >>> are never set (try it! it works!). We don't need nbits as a whole to >>> be const. >> >> What I'm talking about is that by my opinion the both below are equivalent. >> __builtin_constant_p(nbits) >> __builtin_constant_p(nbits & 7) > > They are not. Read Matthew's example again. Assuming that argle is > something non-constant (maybe an argument to the function), the value > of nbits at the time of the bitmap_equal call is _not_ a > compile-time-constant. However, if the compiler is smart (which at > least some versions of gcc are), the compiler may deduce that nbits is > either 8 or 16; there really are no other options. Hence it _is_ > statically known that nbits is divisible by 8, so the expression > nbits&7 _is_ compile-time constant (0), so gcc can change the > bitmap_equal call to a memcmp call.
Yeah, thanks for detailed explanation. So, basically what we do, we consider 1. 3 LSBs _is_ constant, *and* 2. They are equal to 0.
> (It may then either pass a run-time value of nbits>>3 and emit a > single memcmp call, or it may decide to unroll the two options, > creating two memcmp calls with 1 and 2 as compile-time arguments; > these may or may not then in turn be "inlined" to code doing roughly > *(u8*)p1 == *(u8*)p2 and similarly for u16 casts).
-- With Best Regards, Andy Shevchenko
| |