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.
next parent 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: linkBe 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).