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

2005-08-25 Thread Adrian Bunk
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

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

2005-08-25 Thread Adrian Bunk
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

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

2005-08-21 Thread Pekka Enberg
On 8/20/05, Adrian Bunk <[EMAIL PROTECTED]> 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 dechex filename > 25617207

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

2005-08-21 Thread Adrian Bunk
On Sun, Aug 21, 2005 at 10:47:13PM +0300, Pekka Enberg wrote: > On 8/20/05, Adrian Bunk <[EMAIL PROTECTED]> 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

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

2005-08-21 Thread Pekka Enberg
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

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

2005-08-21 Thread Pekka Enberg
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

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

2005-08-21 Thread Adrian Bunk
On Sun, Aug 21, 2005 at 10:47:13PM +0300, Pekka Enberg wrote: On 8/20/05, Adrian Bunk [EMAIL PROTECTED] 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

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

2005-08-21 Thread Pekka Enberg
On 8/20/05, Adrian Bunk [EMAIL PROTECTED] 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 dechex filename 256172075850138

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

2005-08-20 Thread 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 dechex filename 256172075850138 1827016 332943611fc0819 vmlinux-old 25617191

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

2005-08-20 Thread 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 dechex filename 256172075850138 1827016 332943611fc0819 vmlinux-old 25617191