* [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
@ 2006-01-28 22:30 Adrian Bunk
0 siblings, 0 replies; 6+ messages in thread
From: Adrian Bunk @ 2006-01-28 22:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Since size_t has the same size as a long on all architectures, it's
enough for overflow checks to check against ULONG_MAX.
This change could allow a compiler better optimization (especially in
the n=1 case).
The practical effect seems to be positive, but quite small:
text data bss dec hex filename
21762380 5859870 1848928 29471178 1c1b1ca vmlinux-old
21762211 5859870 1848928 29471009 1c1b121 vmlinux-patched
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 20 Aug 2005
--- linux-2.6.13-rc6-mm1-full/include/linux/slab.h.old 2005-08-20 04:10:09.000000000 +0200
+++ linux-2.6.13-rc6-mm1-full/include/linux/slab.h 2005-08-20 04:11:04.000000000 +0200
@@ -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);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
2005-08-21 20:12 ` Pekka Enberg
@ 2005-08-25 16:01 ` Adrian Bunk
0 siblings, 0 replies; 6+ messages in thread
From: Adrian Bunk @ 2005-08-25 16:01 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
2005-08-21 19:54 ` Adrian Bunk
@ 2005-08-21 20:12 ` Pekka Enberg
2005-08-25 16:01 ` Adrian Bunk
0 siblings, 1 reply; 6+ messages in thread
From: Pekka Enberg @ 2005-08-21 20:12 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
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...
Pekka
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
2005-08-21 19:47 ` Pekka Enberg
@ 2005-08-21 19:54 ` Adrian Bunk
2005-08-21 20:12 ` Pekka Enberg
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Bunk @ 2005-08-21 19:54 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
2005-08-20 19:32 Adrian Bunk
@ 2005-08-21 19:47 ` Pekka Enberg
2005-08-21 19:54 ` Adrian Bunk
0 siblings, 1 reply; 6+ messages in thread
From: Pekka Enberg @ 2005-08-21 19:47 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
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.
Pekka
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
@ 2005-08-20 19:32 Adrian Bunk
2005-08-21 19:47 ` Pekka Enberg
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Bunk @ 2005-08-20 19:32 UTC (permalink / raw)
To: linux-kernel
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?
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc6-mm1-full/include/linux/slab.h.old 2005-08-20 04:10:09.000000000 +0200
+++ linux-2.6.13-rc6-mm1-full/include/linux/slab.h 2005-08-20 04:11:04.000000000 +0200
@@ -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);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-01-28 22:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-28 22:30 [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX Adrian Bunk
-- strict thread matches above, loose matches on Subject: below --
2005-08-20 19:32 Adrian Bunk
2005-08-21 19:47 ` Pekka Enberg
2005-08-21 19:54 ` Adrian Bunk
2005-08-21 20:12 ` Pekka Enberg
2005-08-25 16:01 ` Adrian Bunk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).