Re: bad interaction between inlining and sibcall optimization?

[law at redhat dot com]

  In message <200103232104.NAA24193@napali.hpl.hp.com>you write:
  > Attached below is a small test program that demonstrates what appears
  > to be a bad interaction between inlining and the "sibcall"
  > optimization.  Specifically, if I compile the program with the gcc 3.0
  > branch configured for IA-64 using the command "gcc -O3 fac.c", then
  > fac1() gets inlined into fac() as expected, but the inlined recursive
  > call to fac() is not being treated as a "sibcall".  In contrast, if I
  > drop the optimization level to -O2, both fac() and fac1() are sibcall
  > optimized, but of course no inlining is done that way.
What version of the compiler are you using?  We should be able to have
sibcalls and inlining work together in modern versions of GCC
(I don't remember precisely when these issues were addressed).

  > On a related note, it appears to me that the following code in sibcall.c:
  > 
  > 	  /* We must be careful with stack slots which are live at
  > 	     potential optimization sites.
  > 
  > 	     ?!? This test is overly conservative and will be replaced.  */
  > 	  if (frame_offset)
  > 	    goto failure;
  > 
  > prevents this optimization from being used whenever the callee needs a
  > stack frame.  I suspect this prevents many cases where this
  > optimization could be used profitably.  Especially in latency
  > sensitive code, reducing the amount of stack memory being touched can
  > make a big difference performance-wise.  So I'm wondering whether it
  > would be possible to change this code so it wouldn't be quite so
  > conservative.
It's certainly possible and is something I'd like to do or see someone
else do.  Basically someone needs to write code to do proper dataflow
analysis to see if there are any stack slots might be modified by 
the sibcall site.

jeff