Messages in this thread | | | Date | Thu, 25 Aug 2005 18:01:37 +0200 | From | Adrian Bunk <> | Subject | Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX |
| |
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/
| |