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

From: Adrian Bunk
Date: Sun Aug 21 2005 - 16:05:59 EST


On Sun, Aug 21, 2005 at 10:47:13PM +0300, Pekka Enberg wrote:
> On 8/20/05, Adrian Bunk <bunk@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/