From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-5384-listarch-libc-hacker=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 5208 invoked by alias); 3 Aug 2002 12:03:55 -0000
Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sources.redhat.com>
List-Help: <mailto:libc-hacker-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: libc-hacker-owner@sources.redhat.com
Received: (qmail 5192 invoked from network); 3 Aug 2002 12:03:54 -0000
Received: from unknown (HELO sunsite.mff.cuni.cz) (195.113.19.66)
  by sources.redhat.com with SMTP; 3 Aug 2002 12:03:54 -0000
Received: (from jakub@localhost)
	by sunsite.mff.cuni.cz (8.11.6/8.11.6) id g73C3nG26471;
	Sat, 3 Aug 2002 14:03:49 +0200
Date: Sat, 03 Aug 2002 05:03:00 -0000
From: Jakub Jelinek <jakub@redhat.com>
To: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
Cc: libc-hacker@sources.redhat.com
Subject: [PATCH] optimize calloc
Message-ID: <20020803140349.N20867@sunsite.ms.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <20020802004635.Y20867@sunsite.ms.mff.cuni.cz> <20020802092945.24679.qmail@md.dent.med.uni-muenchen.de> <3D4A5446.5030204@redhat.com> <3D4A55F0.5020007@redhat.com> <20020802115506.C20867@sunsite.ms.mff.cuni.cz> <jeit2twmba.fsf@sykes.suse.de> <20020802134512.D20867@sunsite.ms.mff.cuni.cz> <20020802115729.25576.qmail@md.dent.med.uni-muenchen.de> <20020802140412.E20867@sunsite.ms.mff.cuni.cz> <20020802121321.25638.qmail@md.dent.med.uni-muenchen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20020802121321.25638.qmail@md.dent.med.uni-muenchen.de>; from wmglo@dent.med.uni-muenchen.de on Fri, Aug 02, 2002 at 12:13:21PM -0000
X-SW-Source: 2002-08/txt/msg00039.txt.bz2

On Fri, Aug 02, 2002 at 12:13:21PM -0000, Wolfram Gloger wrote:
> > Why not 2^32? size_t is unsigned.
> 
> Yes, however malloc can only handle chunks of a little less than 2^31
> currently, so the _int_malloc later will fail anyway...  But that is
> ok, having a power of two as the compared value wins against this
> micro-optimisation:
> 
> > So you mean something like:
> >   bytes = n * elem_size;
> >   if (__builtin_expect ((a | b) >= 65536, 0)) {
> >     if (bytes / elem_size != n) {
> >       MALLOC_FAILURE_ACTION;
> >       return 0;
> >     }
> >   }
> 
> Hey, nice, avoids the second comparision and ||.  Looks like we have a
> winner?

Ok, here is the patch:

2002-08-03  Jakub Jelinek  <jakub@redhat.com>

	* malloc/malloc.c (public_cALLOc): Only divide if one of arguments
	is bigger than 65535.

--- libc/malloc/malloc.c.jj	2002-08-02 11:47:41.000000000 +0200
+++ libc/malloc/malloc.c	2002-08-03 13:47:50.000000000 +0200
@@ -488,6 +488,9 @@ Void_t *(*__morecore)(ptrdiff_t) = __def
 #endif /* _LIBC */
 #endif /* USE_DL_PREFIX */
 
+#ifndef _LIBC
+#define __builtin_expect(expr, val)	(expr)
+#endif
 
 /*
   HAVE_MEMCPY should be defined if you are not otherwise using
@@ -3466,9 +3469,11 @@ public_cALLOc(size_t n, size_t elem_size
 
   /* size_t is unsigned so the behavior on overflow is defined.  */
   bytes = n * elem_size;
-  if (bytes / elem_size != n) {
-    MALLOC_FAILURE_ACTION;
-    return 0;
+  if (__builtin_expect ((n | elem_size) >= 65536, 0)) {
+    if (bytes / elem_size != n) {
+      MALLOC_FAILURE_ACTION;
+      return 0;
+    }
   }
 
   if (hook != NULL) {


	Jakub