public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vda dot linux at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
Date: Sun, 21 Jun 2009 16:11:00 -0000 [thread overview]
Message-ID: <20090621161115.18259.qmail@sourceware.org> (raw)
In-Reply-To: <bug-30354-12956@http.gcc.gnu.org/bugzilla/>
------- Comment #8 from vda dot linux at googlemail dot com 2009-06-21 16:11 -------
(In reply to comment #7)
> It seems to make sense to bump cost of idiv a bit, given the fact that there
> are register pressure implications.
>
> I would like to however understand what code sequences we produce that are
> estimated to be long but ends up being shorter in practice. Would be possible
> to try to give me some examples of constants where it is important to bump cost
> to 8? It is possible we can simply fix cost estimation in divmod expansion
> instead.
Attached t.c.bz2 is a good source file to experiment with.
With last month's svn snapshot of gcc, I did the following:
/usr/app/gcc-4.4.svn.20090528/bin/gcc -g0 -Os -fomit-frame-pointer
-ffunction-sections -c t.c
objdump -dr t.o >t.asm
with and without the patch, and compared results. (-ffunction-sections are used
merely because they make "objdump -dr" output much more suitable for diffing).
Here is the diff between unpatched and patched gcc's code generated for int_x /
16:
Disassembly of section .text.id_x_16:
0000000000000000 <id_x_16>:
- 0: 89 f8 mov %edi,%eax
- 2: ba 10 00 00 00 mov $0x10,%edx
- 7: 89 d1 mov %edx,%ecx
- 9: 99 cltd
- a: f7 f9 idiv %ecx
- c: c3 retq
+ 0: 8d 47 0f lea 0xf(%rdi),%eax
+ 3: 85 ff test %edi,%edi
+ 5: 0f 49 c7 cmovns %edi,%eax
+ 8: c1 f8 04 sar $0x4,%eax
+ b: c3 retq
int_x / 2:
Disassembly of section .text.id_x_2:
0000000000000000 <id_x_2>:
0: 89 f8 mov %edi,%eax
- 2: ba 02 00 00 00 mov $0x2,%edx
- 7: 89 d1 mov %edx,%ecx
- 9: 99 cltd
- a: f7 f9 idiv %ecx
- c: c3 retq
+ 2: c1 e8 1f shr $0x1f,%eax
+ 5: 01 f8 add %edi,%eax
+ 7: d1 f8 sar %eax
+ 9: c3 retq
As you can see, code become smaller and *much* faster (not even mul insn is
used now).
Here is an example of unsigned_x / 641. In this case, code size is the same,
but the code is faster:
Disassembly of section .text.ud_x_641:
0000000000000000 <ud_x_641>:
- 0: ba 81 02 00 00 mov $0x281,%edx
- 5: 89 f8 mov %edi,%eax
- 7: 89 d1 mov %edx,%ecx
- 9: 31 d2 xor %edx,%edx
- b: f7 f1 div %ecx
+ 0: 89 f8 mov %edi,%eax
+ 2: 48 69 c0 81 3d 66 00 imul $0x663d81,%rax,%rax
+ 9: 48 c1 e8 20 shr $0x20,%rax
d: c3 retq
There is not a single instance of code growth. Either newer gcc is better or
maybe code growth cases are in 32-bit code only.
I will attach t64.asm.diff, take a look if you want to see all changes in
generated code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
next prev parent reply other threads:[~2009-06-21 16:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-02 22:09 [Bug rtl-optimization/30354] New: " vda dot linux at googlemail dot com
2007-01-02 22:45 ` [Bug target/30354] " pinskia at gcc dot gnu dot org
2007-07-25 15:05 ` vda dot linux at googlemail dot com
2007-07-25 15:09 ` vda dot linux at googlemail dot com
2007-07-25 15:17 ` vda dot linux at googlemail dot com
2007-07-25 15:22 ` vda dot linux at googlemail dot com
2009-06-05 16:19 ` aldot at gcc dot gnu dot org
2009-06-06 13:41 ` hubicka at gcc dot gnu dot org
2009-06-21 16:11 ` vda dot linux at googlemail dot com [this message]
2009-06-21 16:12 ` vda dot linux at googlemail dot com
2009-06-21 16:26 ` rguenth at gcc dot gnu dot org
2009-06-21 16:47 ` vda dot linux at googlemail dot com
2009-06-21 16:48 ` vda dot linux at googlemail dot com
2009-06-30 13:36 ` hubicka at gcc dot gnu dot org
2010-01-08 9:06 ` steven at gcc dot gnu dot org
[not found] <bug-30354-4@http.gcc.gnu.org/bugzilla/>
2012-06-28 23:29 ` aldot at gcc dot gnu.org
2013-01-18 10:29 ` vda.linux at googlemail dot com
2021-12-21 11:42 ` pinskia at gcc dot gnu.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=20090621161115.18259.qmail@sourceware.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).