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
Created attachment 9501 [details] testcase gcc -O2 -save-temps -funsafe-loop-optimizations loop.c
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 ***
Why is it that the call to b() is completely optimized away while the call to a() still exists?
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); }
(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.
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.