From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by ozlabs.org (Postfix) with ESMTP id EC564DDF31 for ; Mon, 21 Apr 2008 21:19:53 +1000 (EST) Message-Id: <1208776790.4613.1248992953@webmail.messagingengine.com> From: "Alexander van Heukelum" To: "Ingo Molnar" , "Stephen Rothwell" Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 References: <20080421191231.41a34aef.sfr@canb.auug.org.au> <20080421095102.GB1666@elte.hu> Subject: Re: linux-next: x86-latest/powerpc-next merge conflict In-Reply-To: <20080421095102.GB1666@elte.hu> Date: Mon, 21 Apr 2008 13:19:50 +0200 Cc: linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org, Paul Mackerras List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" said: > > * Stephen Rothwell wrote: > > > Hi all, > > > > Today's linux-next merge of the x86-latest tree got a conflict in > > include/asm-powerpc/bitops.h between commit > > cd008c0f03f3d451e5fbd108b8e74079d402be64 ("generic: implement __fls on > > all 64-bit archs") from the x86-latest tree and commit > > 9f264be6101c42cb9e471c58322fb83a5cde1461 ("[POWERPC] Optimize fls64() > > on 64-bit processors") from the powerpc-next tree. The fixup was not > > quite trivial and is worth a look to see if I got it right. Powerpc would pick up an optimized version via this chain: generic fls64 -> powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (x)). However, the generic version of fls64 first tests the argument for zero. From your code I derive that the count-leading-zeroes instruction for argument zero is defined as cntlzl(0) == BITS_PER_LONG. In that case the explicit test for zero is not needed, which makes the powerpc-specific one added here an improvement over the generic one. I've tried to take a look if you got it right, but the linux-next tree on git.kernel.org is 5 days old. If that's the current state then it's not merged right ;). Greetings, Alexander > Paul, do you agree with those generic bitops changes? Just in case it's > not obvious from previous discussions: we'll push them upstream via a > separate pull request, not via usual x86.git changes. They originated > from x86.git but grew into a more generic improvement for all. They sit > in x86.git for tester convenience but are of course not pure x86 changes > anymore. > > Ingo -- Alexander van Heukelum heukelum@fastmail.fm -- http://www.fastmail.fm - A fast, anti-spam email service.