[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <201010121227.05735.behlendorf1@llnl.gov>
Date: Tue, 12 Oct 2010 12:26:59 -0700
From: Brian Behlendorf <behlendorf1@...l.gov>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <onestero@...hat.com>
Subject: Re: [PATCH] Make div64_u64() precise on 32bit platforms
I'm resending the patch as is and adding what I hope are the right CCs. Also
let me explain why I opted to add abs64() and use the gcc builtin.
>Can't we just improve abs? Say,
I was reluctant to change abs() since it would have a much larger impact on
the code base. Using typeof() should be OK but if any of the callers
mistakenly call abs() with an unsigned value then we could see compiler
warnings about '__x < 0' being a useless conditional.
>This is a bit unusual. I mean, it is not that common to use gcc builtins
>in the normal code. And, it seems, we can use __fls(divisor >> 32) or
>just fls64() instead ?
I opted for the gcc builtin because I felt it made the code more readable. I
also suspect it will perform slightly better than __fls() on some archs. For
example, on powerpc __fls() in implemented using the 'cntlzw' instruction.
It returns (BITS_PER_LONG - 1 - cntlzw) which is wasted work since my
function would immediately undo this to get back cntlzw. If I was lucky the
compiler would optimize this away for me but if I use the builtin I don't
need to take the chance.
--
Thanks,
Brian Behlendorf
View attachment "0001-Fix-div64_u64-for-32bit-platforms.patch" of type "text/plain" (3927 bytes)
View attachment "div64_u64_test.c" of type "text/x-csrc" (1555 bytes)
View attachment "div64_s64_test.c" of type "text/x-csrc" (1533 bytes)
View attachment "README" of type "text/plain" (2085 bytes)
Powered by blists - more mailing lists