public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "steven at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug optimization/6585] useless memory store instructions on x86 Date: Fri, 04 Jul 2003 11:09:00 -0000 [thread overview] Message-ID: <20030704110934.32595.qmail@sources.redhat.com> (raw) In-Reply-To: <20020506130600.6585.bruno@clisp.org> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585 steven at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|0000-00-00 00:00:00 |2003-07-04 11:09:34 date| | Target Milestone|--- |3.4 ------- Additional Comments From steven at gcc dot gnu dot org 2003-07-04 11:09 ------- AFAICT this looks a little better, but still not optimal: .file "6585.c" # GNU C version 3.4 20030703 (experimental) (i686-pc-linux-gnu) # compiled by GNU C version 3.4 20030703 (experimental). # GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31916 # options passed: -O3 -fverbose-asm -march=i686 -mtune=i686 # -fomit-frame-pointer # options enabled: -feliminate-unused-debug-types -fdefer-pop # -fomit-frame-pointer -foptimize-sibling-calls -funit-at-a-time # -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizations # -fthread-jumps -fstrength-reduce -funswitch-loops -fpeephole -fforce-mem # -ffunction-cse -fkeep-static-consts -fcaller-saves -fpcc-struct-return # -fgcse -fgcse-lm -fgcse-sm -floop-optimize -fcrossjumping -fif-conversion # -fif-conversion2 -frerun-cse-after-loop -frerun-loop-opt # -fdelete-null-pointer-checks -fschedule-insns2 -fsched-interblock # -fsched-spec -fbranch-count-reg -freorder-blocks -freorder-functions # -frename-registers -fcprop-registers -fcommon -fverbose-asm -fgnu-linker # -fregmove -foptimize-register-move -fargument-alias -fstrict-aliasing # -fmerge-constants -fzero-initialized-in-bss -fident -fpeephole2 # -fguess-branch-probability -fmath-errno -ftrapping-math -m80387 # -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 # -maccumulate-outgoing-args -mno-red-zone -mtls-direct-seg-refs # -mtune=i686 -march=i686 .text .p2align 4,,15 .globl mul .type mul, @function mul: subl $20, %esp # movl 32(%esp), %ecx # load b0 in ecx movl %edi, 12(%esp) # save %edi movl 24(%esp), %eax # load a0 in eax movl %ebx, 8(%esp) # save %ebx movl 36(%esp), %edi # load b1 in edi movl %ebp, 16(%esp) # save %ebp !!! USELESS movl 16(%esp), %ebp # restore %ebp !!! USELESS mull %ecx # %edx:%eax := a0*b0 movl %edx, %ebx # save high part (==%edx) in %ebx movl 28(%esp), %edx # load a1 in %edx movl %eax, (%esp) # save %eax (now a0*b0 in ebx:(%esp)) movl 24(%esp), %eax # load a0 in eax imull %edx, %ecx # %eax := a1*b0 imull %edi, %eax # %eax := b1*%eax movl 12(%esp), %edi # restore edi addl %eax, %ebx # compute final result... leal (%ebx,%ecx), %eax #... movl 8(%esp), %ebx # restore ebx movl %eax, 4(%esp) # Why not just: movl %eax,%edx movl 4(%esp), %edx # !!! USELESS movl (%esp), %eax # movl (%esp), %eax addl $20, %esp # ret .size mul, .-mul .section .note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.4 20030703 (experimental)" Especially the last "USELESS" is surprising. Why go through the stack here?!
next parent reply other threads:[~2003-07-04 11:09 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20020506130600.6585.bruno@clisp.org> 2003-07-04 11:09 ` steven at gcc dot gnu dot org [this message] 2003-07-10 20:09 ` [Bug optimization/6585] Reduntant store/load instruction pairs on ix86 steven at gcc dot gnu dot org 2003-08-23 1:38 ` [Bug optimization/6585] Redundant " dhazeghi at yahoo dot com 2003-11-25 7:51 ` pinskia at gcc dot gnu dot org 2004-03-17 8:03 ` kazu at cs dot umass dot edu 2004-03-17 12:10 ` bruno at clisp dot org 2004-10-11 2:57 ` [Bug rtl-optimization/6585] " pinskia at gcc dot gnu dot org 2004-10-11 11:55 ` bruno at clisp dot org 2005-06-26 13:35 ` steven at gcc dot gnu dot org 2005-06-27 11:50 ` bruno at clisp 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=20030704110934.32595.qmail@sources.redhat.com \ --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).