Re: [Gcl-devel] Re: sibling call optimization

[Jim Wilson <wilson at specifixinc dot com>]

On Fri, 2004-05-07 at 14:39, Camm Maguire wrote:
> OK.  The full cpp output providing a testcase is included below.  I
> will endeavor to file a bugzilla report on it (never done this before)

I took a quick look.

In the -O2 case, LI2 has two functions calls, both of which are
converted to sibcalls.

In the -O3 case, LI2 has two functions calls.  The second one gets
inlined, so now we have 3 function calls, 1 from the original function,
and two from the inlined function.  The call from the original function
gets converted to a sihcall.  The two calls from the inlined function
are not converted to a sibcall because of a technicality.

The code that creates a sibcall only matches a simple pattern, a call
followed by a branch to the prologue.  In the inlined case, the call
sequence has been optimized a bit, to commonize some code, so we end up
with
	call
	branch common_code:
	call
common_code:
	move reg
	branch epilogue
These are both still sibcalls, but the simple pattern matching code in
sibcall.c can't recognize this.

Overall, the -O3 code isn't really much worse than the -O2 code.  In the
O2 code, calling from LI2->LI1->LI2 involves two sibcalls.  In the -O3
case, the same sequence involves one regular function call.  Note that
LI2 is calling itself, not LI1.  This is because LI1 was inlined into
LI2.  So it is possible that the -O3 code may actually be faster, even
though it has calls instead of sibcalls.

Still, we could do even better if we were able to handle these
sibcalls.  I didn't check to see where the inlined calls got optimized. 
It might be possible to avoid this so that we still get the sibcalls
created.  I am unlikely to look into this further.  I'd suggest filing a
bug report if you really care.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com