This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/14418] New:
- From: "gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Mar 2004 21:11:15 -0000
- Subject: [Bug optimization/14418] New:
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
In a certain case on i386, when a tail call to a function is made
giving the same arguments as the calling function had, those arguments
are loaded from the stack and then stored back, whereas since they're
unchanged I believe there's no need to do that.
Environment:
System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown unknown GNU/Linux
Architecture: i586
<machine, os, target, libraries (multiple lines)>
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
How-To-Repeat:
A file foo.c,
void
foo (int x, int y)
{
bar (2*x);
quux (x, y);
}
compiled with
gcc -O3 -fomit-frame-pointer -S foo.c
produces foo.s,
foo:
subl $28, %esp
movl %ebx, 20(%esp)
movl 32(%esp), %ebx
movl %esi, 24(%esp)
movl 36(%esp), %esi
leal (%ebx,%ebx), %edx
movl %edx, (%esp)
call bar
movl %esi, 36(%esp)
movl 24(%esp), %esi
movl %ebx, 32(%esp)
movl 20(%esp), %ebx
addl $28, %esp
jmp quux
Notice parameters x and y are loaded from 32(%esp) and 36(%esp) into
ebx and esi, and then stored back to the exact same locations for the
tail call to quux. I believe this should be unnecessary.
No doubt when parameters are changed around then some juggling is
necessary, but it'd be nice if gcc could notice when the locations
it's filling already contain the values wanted.
For what it's worth I noticed this in a bit of code in GMP not unlike
the above.
--
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: user42 at zip dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14418