Re: bad interaction between inlining and sibcall optimization?

[David Mosberger <davidm at hpl dot hp dot com>]

>>>>> On Sun, 25 Mar 2001 22:54:53 -0700, law@redhat.com said:

  Jeff>   In message <200103232104.NAA24193@napali.hpl.hp.com>you
  Jeff> 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.

  Jeff> What version of the compiler are you using?  We should be able
  Jeff> to have sibcalls and inlining work together in modern versions
  Jeff> of GCC (I don't remember precisely when these issues were
  Jeff> addressed).

Sorry, I left out that info by accident:

	gcc version 3.0 20010322 (prerelease)

  >> So I'm wondering whether it would be possible to change this code
  >> so it wouldn't be quite so conservative.

  Jeff> It's certainly possible and is something I'd like to do or see
  Jeff> someone else do.  Basically someone needs to write code to do
  Jeff> proper dataflow analysis to see if there are any stack slots
  Jeff> might be modified by the sibcall site.

How hard is this?  I assume to a first degree of approximation, you
could simply check whether any of the automatic variables have their
address taken.  Or are there corner cases that this would miss?

	--david