Bug 23414

Summary: const function is not dectected for functions with non infinite loops
Product: gcc Reporter: Thomas Kho <tkho>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: enhancement CC: gcc-bugs
Priority: P2 Keywords: missed-optimization
Version: 4.1.0   
Target Milestone: ---   
Host: i686-unknown-linux-gnu Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2006-02-20 18:34:29
Attachments: testcase

Description Thomas Kho 2005-08-16 00:58:28 UTC
I built the attached test case with -O2 -save-temps -funsafe-loop-optimizations.

The entire call to a() should be optimized away if the loop optimization works
right, but it's not.

The assembly shows these three useless instructions left in a():
a:
        pushl   %ebp
        movl    %esp, %ebp
        popl    %ebp
        ret
Comment 1 Thomas Kho 2005-08-16 00:59:45 UTC
Created attachment 9501 [details]
testcase

gcc -O2 -save-temps -funsafe-loop-optimizations loop.c
Comment 2 Andrew Pinski 2005-08-16 01:05:16 UTC
The three instructions are the setup of the frame pointer.

This is a dup of bug 13822.  Either use -fomit-frame-pointer or convince someone to turn on -fomit-
frame-pointer for x86 by default.

*** This bug has been marked as a duplicate of 13822 ***
Comment 3 Thomas Kho 2005-08-16 01:11:00 UTC
Why is it that the call to b() is completely optimized away while the call to
a() still exists?
Comment 4 Andrew Pinski 2005-08-16 01:23:36 UTC
The issue here is more complex.  We are not dected the function with the loop as constant so we don't 
mark it as the function a as not having side effects.

The most ovbvious way to fix this would do the ipa optimizations on the ssa level where we can get the 
loop information and check to see if the loops are finite.

A simple example is even without -funsafe-loop-optimization:

void a(int start, int finish) {
  for (; start < finish; ++start) {
  }
}
int main() {
  int x = 0, y = 99;
  a(x, y);
}
Comment 5 Andrew Pinski 2005-08-16 01:25:40 UTC
(In reply to comment #4)
> The most ovbvious way to fix this would do the ipa optimizations on the ssa level where we can get 
> the loop information and check to see if the loops are finite.

I should mention that will not happen until at least 4.2.0.
Comment 6 Thomas Koenig 2009-01-31 22:00:03 UTC
Test case now generates this assembly:

.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
#APP
# 18 "gaga.c" 1
        #start1
# 0 "" 2
# 20 "gaga.c" 1
        #end1
# 0 "" 2
# 22 "gaga.c" 1
        #start2
# 0 "" 2
# 24 "gaga.c" 1
        #end2
# 0 "" 2
# 26 "gaga.c" 1
        #start3
# 0 "" 2
# 30 "gaga.c" 1
        #end3
# 0 "" 2
#NO_APP
        popl    %ebp
        ret
        .size   main, .-main
        .ident  "GCC: (GNU) 4.4.0 20090124 (experimental)"
        .section        .note.GNU-stack,"",@progbits

Fixed.