This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug optimization/14418] New:


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]