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

[Adrian Bunk <bunk@stusta.de>]

On Sun, Aug 21, 2005 at 11:12:06PM +0300, Pekka Enberg wrote:
> On Sun, Aug 21, 2005 at 10:47:13PM +0300, Pekka Enberg wrote:
> > > 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.
> 
> On 8/21/05, Adrian Bunk <bunk@stusta.de> wrote:
> > 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.
> 
> Yes, that's my point. The second argument (size) is virtually always
> sizeof() whereas the first one (n) is sometimes a variable. GCC
> currently does not optimize away the division when n is not a
> constant.
> 
> Looking at 2.6.13-rc6-mm1, we have roughly 15 callers with the first
> parameter being a variable. The compiler would be able to get rid of
> one comparison and division instruction for each of these so looks
> like we could shave off some more bytes...

With gcc 4.0.1:

    text           data     bss     dec             hex filename
25675334        5851630 1819976 33346940        1fcd57c vmlinux-my-patch
25675366        5851630 1819976 33346972        1fcd59c vmlinux-your-patch

INT_MAX -> ULONG_MAX is correct, even though it doesn't seem to make a 
difference with today's gcc.

Trying to change the code in a way that gcc will produce better code 
doesn't seem to be worth it (except in extreme hot paths).

>                             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/