public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vda.linux at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/21182] gcc can use registers but uses stack instead
Date: Fri, 18 Jan 2013 00:48:00 -0000	[thread overview]
Message-ID: <bug-21182-4-ZZi1jU1xB3@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-21182-4@http.gcc.gnu.org/bugzilla/>


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

--- Comment #6 from Denis Vlasenko <vda.linux at googlemail dot com> 2013-01-18 00:48:23 UTC ---
Created attachment 29200
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29200
Updated testcase, build heper, and results of testing with different gcc
versions

Tarball contains:

serpent.c:
the original testcase, only with "#ifdef NAIL_REGS" instead of "#if 0" which
allows test compiles w/o editing it. Basically, "gcc -DNAIL_REGS serpent.c"
will try to force gcc to use only registers instead of stack.

gencode.sh:
builds serpent.c with -O2 and -O3, with and without -DNAIL_REGS. The object
file names contain gcc version and used options. Then they are objdump'ed and
output saved. Tweakable with setting $PREFIX and/or $CC.
No -fomit-frame-pointer used: the testcase can be compiled so that stack is not
used even without that option.

Disassembly:
serpent-O2-3.4.3.asm
serpent-O2-4.2.1.asm
serpent-O2-4.6.3.asm
serpent-O2-DNAIL_REGS-3.4.3.asm
serpent-O2-DNAIL_REGS-4.2.1.asm
serpent-O2-DNAIL_REGS-4.6.3.asm
serpent-O3-3.4.3.asm
serpent-O3-4.2.1.asm
serpent-O3-4.6.3.asm
serpent-O3-DNAIL_REGS-3.4.3.asm
serpent-O3-DNAIL_REGS-4.2.1.asm
serpent-O3-DNAIL_REGS-4.6.3.asm

Object files:
   text    data     bss     dec     hex filename
   3260       0       0    3260     cbc serpent-O2-DNAIL_REGS-3.4.3.o
   3260       0       0    3260     cbc serpent-O3-DNAIL_REGS-3.4.3.o
   3292       0       0    3292     cdc serpent-O3-3.4.3.o
   3536       0       0    3536     dd0 serpent-O2-4.6.3.o
   3536       0       0    3536     dd0 serpent-O3-4.6.3.o
   3845       0       0    3845     f05 serpent-O2-DNAIL_REGS-4.6.3.o
   3845       0       0    3845     f05 serpent-O3-DNAIL_REGS-4.6.3.o
   3877       0       0    3877     f25 serpent-O2-4.2.1.o
   3877       0       0    3877     f25 serpent-O3-4.2.1.o
   4302       0       0    4302    10ce serpent-O2-3.4.3.o
   4641       0       0    4641    1221 serpent-O2-DNAIL_REGS-4.2.1.o
   4641       0       0    4641    1221 serpent-O3-DNAIL_REGS-4.2.1.o

Take a look inside serpent-O2-DNAIL_REGS-3.4.3.asm file.
This is what I want to get without asm hacks: the smallest code, uses no stack.

gcc-3.4.3 -O3 comes close: it does spill a few words to stack (search for
(%ebp)), but is generally good code (close to ideal?).

All other attempts fare worse:

gcc-3.4.3 -O2: code is significantly worse than -O3.
gcc-4.2.1 -O2/-O3: code is better than gcc-3.4.3 -O2, worse than gcc-4.6.3
gcc-4.6.3 -O2/-O3: six instances of spills to stack . Code is still not as good
as gcc-3.4.3 -O3. (-DNAIL_REGS only confuses it more, unlike 3.4.3).

Stack usage summary:

$ grep 'sub.*,%esp' *.asm | grep -v DNAIL_REGS
serpent-O2-3.4.3.asm:   6:  81 ec 00 01 00 00       sub    $0x100,%esp
serpent-O2-4.2.1.asm:   6:  83 ec 78                sub    $0x78,%esp
serpent-O2-4.6.3.asm:   4:  83 ec 04                sub    $0x4,%esp
serpent-O3-4.2.1.asm:   6:  83 ec 78                sub    $0x78,%esp
serpent-O3-4.6.3.asm:   4:  83 ec 04                sub    $0x4,%esp

(serpent-O3-3.4.3.asm is not listed, but it allocates and uses one word on
stack by push insn).


Modules with best (= minimal) stack usage:

$ grep -F -e '(%esp)' -e '(%ebp)' serpent-O2-DNAIL_REGS-3.4.3.asm
   6:   8b 75 08                mov    0x8(%ebp),%esi
   9:   8b 7d 10                mov    0x10(%ebp),%edi
 ca9:   8b 75 0c                mov    0xc(%ebp),%esi

$ grep -F -e '(%esp)' -e '(%ebp)' serpent-O3-3.4.3.asm
   7:   8b 7d 08                mov    0x8(%ebp),%edi
   a:   8b 4d 10                mov    0x10(%ebp),%ecx
 18c:   89 7d f0                mov    %edi,-0x10(%ebp)
 1dd:   8b 45 f0                mov    -0x10(%ebp),%eax
 23b:   8b 75 f0                mov    -0x10(%ebp),%esi
 299:   8b 7d f0                mov    -0x10(%ebp),%edi
 432:   8b 55 f0                mov    -0x10(%ebp),%edx
 4a0:   8b 4d f0                mov    -0x10(%ebp),%ecx
 50e:   8b 7d f0                mov    -0x10(%ebp),%edi
 84f:   8b 45 f0                mov    -0x10(%ebp),%eax
 8b9:   8b 75 f0                mov    -0x10(%ebp),%esi
 923:   8b 7d f0                mov    -0x10(%ebp),%edi
 cb6:   8b 55 0c                mov    0xc(%ebp),%edx

$ grep -F -e '(%esp)' -e '(%ebp)' serpent-O3-4.6.3.asm
   7:   8b 4c 24 20             mov    0x20(%esp),%ecx
   b:   8b 44 24 18             mov    0x18(%esp),%eax
 22e:   89 0c 24                mov    %ecx,(%esp)
 239:   23 3c 24                and    (%esp),%edi
 588:   89 0c 24                mov    %ecx,(%esp)
 58f:   23 3c 24                and    (%esp),%edi
 8f4:   89 0c 24                mov    %ecx,(%esp)
 8fd:   23 3c 24                and    (%esp),%edi
 c60:   89 0c 24                mov    %ecx,(%esp)
 c6b:   23 3c 24                and    (%esp),%edi
 d37:   89 14 24                mov    %edx,(%esp)
 d5a:   8b 44 24 1c             mov    0x1c(%esp),%eax
 d5e:   33 14 24                xor    (%esp),%edx


Conclusion:
gcc-4.6.3 -O3 was close to ideal.
gcc-4.2.1 is worse.
gcc-4.6.3 got better a bit, still not as good as gcc-4.6.3 -O3.


       reply	other threads:[~2013-01-18  0:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-21182-4@http.gcc.gnu.org/bugzilla/>
2013-01-18  0:48 ` vda.linux at googlemail dot com [this message]
2013-01-18  0:51 ` vda.linux at googlemail dot com
2013-01-18  0:55 ` vda.linux at googlemail dot com
2013-01-18  0:57 ` pinskia at gcc dot gnu.org
2013-01-18 10:39 ` [Bug rtl-optimization/21182] [4.6/4.7/4.8 Regression] " rguenth at gcc dot gnu.org
2013-01-20 14:40 ` vda.linux at googlemail dot com
2013-03-13 20:38 ` steven at gcc dot gnu.org
2013-04-12 15:18 ` [Bug rtl-optimization/21182] [4.7/4.8/4.9 " jakub at gcc dot gnu.org
2014-06-12 13:49 ` [Bug rtl-optimization/21182] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
2014-12-19 13:35 ` [Bug rtl-optimization/21182] [4.8/4.9/5 " jakub at gcc dot gnu.org
2015-06-23  8:35 ` [Bug rtl-optimization/21182] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
2015-06-26 20:03 ` [Bug rtl-optimization/21182] [4.9/5/6 " jakub at gcc dot gnu.org
2015-06-26 20:32 ` jakub at gcc dot gnu.org
2021-01-26 13:43 ` [Bug rtl-optimization/21182] [8/9/10/11 " rguenth at gcc dot gnu.org
2021-04-27 11:37 ` [Bug rtl-optimization/21182] [8/9/10/11/12 " jakub at gcc dot gnu.org
2021-07-28  7:04 ` [Bug rtl-optimization/21182] [9/10/11/12 " rguenth at gcc dot gnu.org
2022-04-21  7:47 ` rguenth at gcc dot gnu.org
2023-05-29 10:01 ` [Bug rtl-optimization/21182] [10/11/12/13/14 " jakub at gcc dot gnu.org
2023-07-15  7:36 ` [Bug rtl-optimization/21182] [11/12/13/14 " pinskia at gcc dot gnu.org
2005-04-23 22:30 [Bug rtl-optimization/21182] New: " vda at port dot imtp dot ilyichevsk dot odessa dot ua
2005-04-23 22:32 ` [Bug rtl-optimization/21182] " vda at port dot imtp dot ilyichevsk dot odessa dot ua
2005-04-23 22:39 ` pinskia at gcc dot gnu dot org
2005-04-23 22:49 ` vda at port dot imtp dot ilyichevsk dot odessa dot ua
2005-04-23 22:54 ` vda at port dot imtp dot ilyichevsk dot odessa dot ua
2005-04-24 13:05 ` vda at port dot imtp dot ilyichevsk dot odessa dot ua
2005-05-07 15:24 ` steven 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=bug-21182-4-ZZi1jU1xB3@http.gcc.gnu.org/bugzilla/ \
    --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).