Re: linux-next: x86-latest/powerpc-next merge conflict

["Alexander van Heukelum" <heukelum@fastmail.fm>]

On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <mingo@elte.hu> said:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> 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.