Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX

[Adrian Bunk <bunk@stusta.de>]

On Sun, Aug 21, 2005 at 10:47:13PM +0300, Pekka Enberg wrote:
> On 8/20/05, Adrian Bunk <bunk@stusta.de> wrote:
> > This change could (at least in theory) allow a compiler better
> > optimization (especially in the n=1 case).
> > 
> > The practical effect seems to be nearly zero:
> >     text           data     bss      dec            hex filename
> > 25617207        5850138 1827016 33294361        1fc0819 vmlinux-old
> > 25617191        5850138 1827016 33294345        1fc0809 vmlinux-patched
> > 
> > Is there any reason against this patch?
> 
> Looks ok to me.
> 
> On 8/20/05, Adrian Bunk <bunk@stusta.de> wrote:
> >  static inline void *kcalloc(size_t n, size_t size, unsigned int __nocast flags)
> >  {
> > -       if (n != 0 && size > INT_MAX / n)
> > +       if (n != 0 && size > ULONG_MAX / n)
> 
> You'll probably get even better code if you change the above to:
> 
>     if (size != 0 && n > ULONG_MAX / size)
> 
> Reason being that size is virtually always a constant so the compiler
> can evaluate the division at compile-time.

I doubt this would make any difference.

And besides, except in some rare cases, the second argument is a 
sizeof(foo) whose size is already known at compile time.

>                                   Pekka

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/