GCC Bugzilla – Bug 11830
Unnecessary call to an empty function
Last modified: 2004-04-03 01:11:11 UTC
If a (non-virtual) function doesn't have any instructions or the caller function(s) are not dependent on the result of the called function (which is hard to identify), then the function call instruction is unnecessary at the caller. The unit-at-a-time algorithm doesn't solve this problem either. --- c example --- int a,b; int get(int i) { return i; } void foo() { a=10; b=get(a); } --- arm code --- get: mov pc, lr <- RETURN foo: ldr r2, .L3 mov r3, #10 mov ip, sp stmfd sp!, {fp, ip, lr, pc} mov r0, r3 str r3, [r2, #0] sub fp, ip, #4 bl get <- OLD ldr r3, .L3+4 str r0, [r3, #0] ldmea fp, {fp, sp, pc} --- possible solution --- get: mov pc, lr <- RETURN foo: ldr r2, .L3 mov r3, #10 mov ip, sp stmfd sp!, {fp, ip, lr, pc} mov r0, r3 str r3, [r2, #0] sub fp, ip, #4 ldr r3, .L3+4 str r0, [r3, #0] ldmea fp, {fp, sp, pc}
In your example , you depend on the result of the call so you cannot remove the function call because b is global (unless GCC can see all of your code). But here is an example where GCC does not remove the function at all (confirmed on the mainline 20030806): int a; int get(int i) { return i; } void foo() { int b; a=10; b= get(a); }
Subject: Re: Unnecessary call to an empty function > In your example , you depend on the result of the call so you cannot remove the function > call because b is global (unless GCC can see all of your code). > But here is an example where GCC does not remove the function at all (confirmed on the > mainline 20030806): > int a; > int get(int i) > { > return i; > } > void foo() > { > int b; > a=10; > b= get(a); > } Gcc will do these types of optimization with -finline-functions. However, that can make code bigger (the inlining code really needs some work to make it more conservative with -Ospace). R.
The tree-ssa branch does not optimize this either but it is most likely will do so in the future.
If I get rid of the assignment of b (in my example or yours) GCC does remove the function call.
Actually this was fixed for 3.0.
pinskia at gcc dot gnu dot org wrote: > Actually this was fixed for 3.0. I did not understand it clearly. This was fixed for 3.0.x, but the mainline still contains it? Why? I made some test with different arm-elf-gcc versions (3.0, 3.0.1, 3.1, 3.2, 3.3, 3.4), and I found no one solved the problem (with -Os). I think this bug has to be reopened because of the mainline (at least).
(In reply to comment #6) See my earlier comment.
Fixed in 3.5.0, sorry for closing this before, I did not understand the bug which you were reporting.