Re: [PATCH v4 05/10] x86: Add functions for 64-bit integer arithmetic

[Haozhong Zhang <haozhong.zhang@intel.com>]

On 02/16/16 02:39, Jan Beulich wrote:
> >>> On 16.02.16 at 10:02, <haozhong.zhang@intel.com> wrote:
> > On 02/05/16 21:36, Jan Beulich wrote:
> >> >>> On 17.01.16 at 22:58, <haozhong.zhang@intel.com> wrote:
> >> > This patch adds several functions to take multiplication, division and
> >> > shifting involving 64-bit integers.
> >> > 
> >> > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
> >> > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >> > ---
> >> > Changes in v4:
> >> >  (addressing Jan Beulich's comments)
> >> >  * Rewrite mul_u64_u64_shr() in assembly.
> >> 
> >> Thanks, but it puzzles me that the other one didn't get converted
> >> as well. Anyway, I'm not going to make this a requirement, since
> >> at least it appears to match Linux'es variant.
> >>
> > 
> > I can't remember why I didn't rewrite mul_u64_u32_div(), especially when
> > it can be easily implemented as
> > 
> > static inline u64 mul_u64_u32_div(u64 a, u32 mul, u32 divisor)
> > {
> >     u64 quotient, remainder;
> >     
> >     asm volatile ( "mulq %3; divq %4"
> >                    : "=a" (quotient), "=d" (remainder)
> >                    : "0" (a), "rm" ((u64) mul), "c" ((u64) divisor) );
> > 
> >     return quotient;
> > }
> > 
> > I'll modify it in the next version.
> 
> Looks better, but the constraints aren't right (needing =& for
> both outputs, and "c" being too narrow). But iirc the question
> was anyway whether to better have even lower overhead inline
> assembly and single point of use.
>

Thank you for pointing out the constraint error! And indeed every
function in this patch is used at single point. In my reply to your
comments for patch 6, I'll modify and inline them at their use points.

Haozhong