From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751900AbdFHNoC (ORCPT ); Thu, 8 Jun 2017 09:44:02 -0400 Received: from mail-ua0-f170.google.com ([209.85.217.170]:34466 "EHLO mail-ua0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751738AbdFHNny (ORCPT ); Thu, 8 Jun 2017 09:43:54 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170607142924.28552-1-willy@infradead.org> <20170607142924.28552-4-willy@infradead.org> <20170608025556.GB20010@bombadil.infradead.org> From: Rasmus Villemoes Date: Thu, 8 Jun 2017 15:43:52 +0200 Message-ID: Subject: Re: [PATCH 3/3] bitmap: Use memcmp optimisation in more situations To: Andy Shevchenko Cc: Matthew Wilcox , "linux-kernel@vger.kernel.org" , Andrew Morton , Martin Schwidefsky , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8 June 2017 at 14:31, Andy Shevchenko wrote: > On Thu, Jun 8, 2017 at 5:55 AM, Matthew Wilcox 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. (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).