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?!


       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: 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).