kcalloc(): INT_MAX -> ULONG_MAX
RFC PATCH 1/1 kcalloc(): INT_MAX -> ULONG_MAX
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?
include/linux/slab.h renamed from include/linux/slab.h.old +1 -1
@@ -113,7 +113,7 @@*/ 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)return NULL ;return kzalloc (n * size, flags); }
Quoted 6 lines · Pekka Enberg
Quoted 6 lines
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.
Quoted 4 lines · Adrian Bunk
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...
Pekka
Quoted 19 lines · Pekka Enberg
Quoted 9 lines · Adrian Bunk
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 filename25617207 5850138 1827016 33294361 1fc0819 vmlinux-old 25617191 5850138 1827016 33294345 1fc0809 vmlinux-patchedIs there any reason against this patch?
Looks ok to me.
include/linux/slab.h line 116
Quoted 4 lines · Adrian Bunk
static inline void *kcalloc(size_t n,
size_tsize, unsigned int__nocastflags) {include/linux/slab.h renamed from include/linux/slab.h.old +1
-1-if (n !=0 && size >INT_MAX / n) +if (n !=0 && size >ULONG_MAX / n)
Quoted 6 lines
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.
Quoted 1 line
Pekka
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 9 lines · Adrian Bunk
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 filename25617207 5850138 1827016 33294361 1fc0819 vmlinux-old 25617191 5850138 1827016 33294345 1fc0809 vmlinux-patchedIs there any reason against this patch?
Looks ok to me.
include/linux/slab.h line 116
Quoted 4 lines · Adrian Bunk
static inline void *kcalloc(size_t n,
size_tsize, unsigned int__nocastflags) {include/linux/slab.h renamed from include/linux/slab.h.old +1
-1-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.
Pekka
Quoted 19 lines · Pekka Enberg
Quoted 6 lines · Pekka Enberg
Quoted 6 lines
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.
Quoted 4 lines · Adrian Bunk
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.
Quoted 4 lines
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).
Quoted 1 line
Pekka
cu
Adrian
Signature · 4 lines
"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