From: Sebastian Biallas <sb@biallas.net>
To: gcc-help@gcc.gnu.org
Subject: Code quality with uint64_t on x86
Date: Sun, 09 Apr 2006 02:18:00 -0000 [thread overview]
Message-ID: <44386EDE.4060402@biallas.net> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
With uint64_t types I encountered some suboptimal code with gcc 4.1:
$ uname -a
Linux meisenmann 2.6.16 #1 PREEMPT Wed Mar 22 20:40:14 CET 2006 i686 AMD
Athlon(tm) Processor AuthenticAMD GNU/Linux
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.0/work/gcc-4.1.0/configure
- --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0
- --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include
- --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0
- --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/man
- --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/info
- --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include/g++-v4
- --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
- --enable-nls --without-included-gettext --with-system-zlib
- --disable-checking --disable-werror --disable-libunwind-exceptions
- --disable-multilib --disable-libmudflap --disable-libssp
- --disable-libgcj --enable-languages=c,c++ --enable-shared
- --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.0 (Gentoo 4.1.0)
$ cat t.cc
#include <stdint.h>
typedef uint32_t uint32;
typedef uint64_t uint64;
static inline uint32 delinearize(uint32 d)
{
return d*0x8088405+1; /* there's magic in here... */
}
uint64 delinearize64(uint64 d)
{
return (uint64(delinearize(d>>32))<<32) | delinearize(d);
/* there's less magic in here... */
}
$ g++ -S -O2 -o t.S t.cc
$ cat t.S
.file "t.cc"
.text
.align 2
.p2align 4,,15
.globl _Z13delinearize64y
.type _Z13delinearize64y, @function
_Z13delinearize64y:
.LFB14:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
pushl %ebx
.LCFI2:
movl 12(%ebp), %ebx
movl 8(%ebp), %ecx
movl %ebx, %edx [0]
movl %ecx, %eax
movl %edx, %eax
imull $134775813, %eax, %eax
xorl %edx, %edx [1]
imull $134775813, %ecx, %ecx
xorl %edx, %edx [1]
popl %ebx
incl %eax
popl %ebp
movl %eax, %edx
incl %ecx
movl $0, %eax [3]
orl %ecx, %eax
ret
.LFE14:
.size _Z13delinearize64y, .-_Z13delinearize64y
.globl __gxx_personality_v0
.ident "GCC: (GNU) 4.1.0 (Gentoo 4.1.0)"
.section .note.GNU-stack,"",@progbits
Well, this doesn't look good. For example:
[0] What's all this moving for? imull is one of the most versatile x86
instructions :)
Additional points for clobbering %ebx for no real use.
[1] Useless use of xor award
[2] LOL
Are these known bugs or should I file a PR?
Additionally, this gets worse if I remove the "inline" keyword:
[same program with "inline" removed]
$ cat t2.cc
.file "t2.cc"
.text
.align 2
.p2align 4,,15
.type _Z11delinearizej, @function
_Z11delinearizej:
.LFB13:
imull $134775813, %eax, %eax
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
popl %ebp
incl %eax
ret
.LFE13:
.size _Z11delinearizej, .-_Z11delinearizej
.globl __gxx_personality_v0
.align 2
.p2align 4,,15
.globl _Z13delinearize64y
.type _Z13delinearize64y, @function
_Z13delinearize64y:
.LFB14:
pushl %ebp
.LCFI2:
movl %esp, %ebp
.LCFI3:
subl $16, %esp
.LCFI4:
movl %esi, -4(%ebp)
.LCFI5:
movl 12(%ebp), %esi
movl %ebx, -8(%ebp)
.LCFI6:
movl 8(%ebp), %ebx
movl %esi, %edx
movl %ebx, %eax
movl %edx, %eax
xorl %edx, %edx
call _Z11delinearizej
movl $0, -12(%ebp)
movl -12(%ebp), %edx
movl %eax, -16(%ebp)
movl -16(%ebp), %eax
movl %eax, %edx
movl $0, %eax
movl %eax, -16(%ebp)
movl %ebx, %eax
movl %edx, -12(%ebp)
call _Z11delinearizej
movl -12(%ebp), %edx
movl -8(%ebp), %ebx
movl -4(%ebp), %esi
movl %eax, %ecx
movl -16(%ebp), %eax
movl %ebp, %esp
popl %ebp
orl %ecx, %eax
ret
.LFE14:
.size _Z13delinearize64y, .-_Z13delinearize64y
.ident "GCC: (GNU) 4.1.0 (Gentoo 4.1.0)"
.section .note.GNU-stack,"",@progbits
Why doesn't gcc automatically inline "static uint32 delinearize(uint32
d)" here?
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRDhu3v81M8QtvOSJAQJnSAgAl6AQhd7vaIvX3Uzz21D6jcsCXQJ2Q07v
V6hXuJSwXdT90CM0ns06E9TeRgwDFMeqTTtocIK7APOxcG0MyAI9ccU8y0v7aMEv
gwmVvCzsjnj4hXuXqy6GIAwhCxoH/Y4k7F868wFGGopgdFAbwhdyaRohoJyPoA7j
WiVb8sSFuDWI+72XUDZGuHhu3jdGpif7Hg063URnfG1T5kQzE6hvF6aoPQHnlzGA
biGmAyld7U9h9xpQ7l6zlXVSY77btUGXYMXnTwp27g/UIxzZDYd7MBlgKt7Zou5h
A3JQj390tDxVgwxOb2ZKJZ2LcFZrU9nOHhKr6ZEjHQvdwdSvoXPMng==
=KcR4
-----END PGP SIGNATURE-----
reply other threads:[~2006-04-09 2:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=44386EDE.4060402@biallas.net \
--to=sb@biallas.net \
--cc=gcc-help@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).