public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
Date: Sun, 21 Aug 2005 23:12:06 +0300	[thread overview]
Message-ID: <84144f0205082113123049afe2@mail.gmail.com> (raw)
In-Reply-To: <20050821195434.GC5726@stusta.de>

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

  reply	other threads:[~2005-08-21 21:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-20 19:32 [RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX Adrian Bunk
2005-08-21 19:47 ` Pekka Enberg
2005-08-21 19:54   ` Adrian Bunk
2005-08-21 20:12     ` Pekka Enberg [this message]
2005-08-25 16:01       ` Adrian Bunk
  -- strict thread matches above, loose matches on Subject: below --
2006-01-28 22:30 Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84144f0205082113123049afe2@mail.gmail.com \
    --to=penberg@gmail.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox