linux-next: x86-latest/powerpc-next merge conflict
Alexander van Heukelum
heukelum at fastmail.fm
Mon Apr 21 21:19:50 EST 2008
On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <mingo at elte.hu> said:
>
> * Stephen Rothwell <sfr at 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 at fastmail.fm
--
http://www.fastmail.fm - A fast, anti-spam email service.
More information about the Linuxppc-dev
mailing list