Received: (at submit) by bugs.debian.org; 10 Feb 2001 23:34:16 +0000
From herbert@gondor.apana.org.au Sat Feb 10 17:34:16 2001
Return-path: <herbert@gondor.apana.org.au>
Received: from gondor.apana.org.au [::ffff:203.14.152.114] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14RjWw-0008Ke-00; Sat, 10 Feb 2001 17:34:15 -0600
Received: (from herbert@localhost)
	by gondor.apana.org.au (8.11.1/8.11.1/Debian 8.11.0-6) id f1ANY8802784;
	Sun, 11 Feb 2001 10:34:08 +1100
Date: Sun, 11 Feb 2001 10:34:08 +1100
Message-Id: <200102102334.f1ANY8802784@gondor.apana.org.au>
From: <herbert@gondor.apana.org.au>
Subject: gcc: builtin memcmp() could be optimised
To: submit@bugs.debian.org
X-Mailer: bug 3.3.7
Delivered-To: submit@bugs.debian.org

Package: gcc
Version: 1:2.95.2-20
Severity: wishlist

If I did a memcmp() on two 32-bit objects and used the result value as
a boolean, then memcmp() should not go to the trouble of determining the
order of those two objects.  It should simply determine whether they're
equal or not.  This can be generalised to objects of any size.

For example, the code

int main() {
	return !memcmp("abcd", "efgh", 4);
}

produces the assembly (-S -g -O2),

        movl $.LC1,%esi
        movl $.LC0,%edi
        movl $4,%ecx
        cld
        testb $0,%al
        repz
        cmpsb
        sete %al

which is a waste because it could've simply loaded the two objects into
registers and compared them.  The same is true on other architectures as
well.

I have reproduced this problem with gcc 2.95.3.

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondor 2.2.17 #1 Mon Sep 11 22:22:16 EST 2000 i586 unknown

Versions of the packages gcc depends on:
ii  binutils       2.10.1.0.2-1   The GNU assembler, linker and binary utiliti
ii  cpp            2.95.2-20      The GNU C preprocessor.
ii  libc6          2.2.1-1        GNU C Library: Shared libraries and Timezone