public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "willy at w dot ods dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug optimization/11873] New: inefficient use of registers induces size and time overhead
Date: Sun, 10 Aug 2003 08:39:00 -0000	[thread overview]
Message-ID: <20030810083857.11873.willy@w.ods.org> (raw)

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11873

           Summary: inefficient use of registers induces size and time
                    overhead
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: willy at w dot ods dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-linux-gnu
  GCC host triplet: i586-linux-gnu
GCC target triplet: i586-linux-gnu

I wrote a simple test function which uses an unsigned long long arg and returns
its integer part + 1 if not 0, otherwise 0. GCC 3.3.1 passes some intermediate
values through several registers while it's unneeded. Here comes all my analysis.
I hope this can help improving the optimizer.
The following code :

int test(unsigned long long x) {
        if (x) {
                return (int)x + 1;
        }
        else {
                return (int)x;
        }
}

processed this way :

# 1 "bool.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "bool.c"
int test(unsigned long long x) {
        if (x) {
                return (int)x + 1;
        }
        else {
                return (int)x;
        }
}



produces the following code when compiled with gcc 2.95.3 :
(gcc -c -O2 -fomit-frame-pointer bool.c)

00000000 <test>:
   0:   8b 54 24 04             mov    0x4(%esp,1),%edx
   4:   8b 4c 24 08             mov    0x8(%esp,1),%ecx
   8:   89 d0                   mov    %edx,%eax
   a:   09 c8                   or     %ecx,%eax
   c:   75 03                   jne    11 <test+0x11>
   e:   89 d0                   mov    %edx,%eax
  10:   c3                      ret
  11:   8d 42 01                lea    0x1(%edx),%eax
  14:   c3                      ret
  15:   8d 76 00                lea    0x0(%esi),%esi
  18:


and this one with gcc-3.3.1 :
(gcc-3.3.1 -c -O2 -fomit-frame-pointer bool.c)

00000000 <test>:
   0:   53                      push   %ebx
   1:   8b 4c 24 0c             mov    0xc(%esp,1),%ecx
   5:   8b 54 24 08             mov    0x8(%esp,1),%edx
   9:   89 cb                   mov    %ecx,%ebx
   b:   89 d0                   mov    %edx,%eax
   d:   09 d3                   or     %edx,%ebx
   f:   74 03                   je     14 <test+0x14>
  11:   8d 42 01                lea    0x1(%edx),%eax
  14:   5b                      pop    %ebx
  15:   c3                      ret
  16:   8d 76 00                lea    0x0(%esi),%esi
  19:   8d bc 27 00 00 00 00    lea    0x0(%edi,1),%edi
  20:


the EBX register is used and clobbered for nothing here. The
same code could be written this way, which is fully equivalent
and saves some cycles and bytes :

00000000 <test>:
   0:   8b 4c 24 0c             mov    0xc(%esp,1),%ecx
   4:   8b 54 24 08             mov    0x8(%esp,1),%edx
   8:   89 d0                   mov    %edx,%eax
   a:   09 d1                   or     %edx,%ecx
   c:   74 03                   je     11 <test+0x11>
   e:   8d 42 01                lea    0x1(%edx),%eax
  11:   c3                      ret
  12:

Now we can also save EDX and some more bytes :

00000000 <test>:
   0:   8b 4c 24 0c             mov    0xc(%esp,1),%ecx
   4:   8b 54 24 08             mov    0x8(%esp,1),%eax
   a:   09 c1                   or     %eax,%ecx
   c:   74 01                   je     f <test+0xf>
   e:   41                      inc    %eax
   f:   c3                      ret
  10:

Here are the compilers versions :

wtap:~/dev$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)

wtap:~/dev$ gcc-3.3.1 -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.1/specs
Configured with: ./configure --prefix=/usr --with-cpu=i386 --host=i586-pc-linux-gnu --enable-languages=c,c++ --disable-nls --disable-locale --enable-shared --enable-target-optspace --enable-version-specific-runtime-libs --program-suffix=-3.3.1 --enable-threads
Thread model: posix
gcc version 3.3.1


             reply	other threads:[~2003-08-10  8:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-10  8:39 willy at w dot ods dot org [this message]
2003-08-10 13:52 ` [Bug optimization/11873] " pinskia at gcc dot gnu dot org
2003-08-23  1:15 ` dhazeghi at yahoo dot com
2004-06-03  4:27 ` [Bug rtl-optimization/11873] " pinskia at gcc dot gnu dot org
2004-06-03  4:29 ` pinskia at gcc dot gnu dot org
2004-11-08 23:44 ` pinskia at gcc dot gnu dot org
2004-11-13  6:01 ` pinskia at gcc dot gnu dot org

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=20030810083857.11873.willy@w.ods.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).