Re: tail call optimizations

[Jeffrey A Law <law at cygnus dot com>]

  In message <jmu2hyw01h.fsf@envy.cygnus.com>you write:
  > This means that you can't do tail call optimisations when the tail
  > call is in a region where exceptions can be caught (in that
  > procedure), but in that case it's not really a 'tail call'.
Precisely.  According to Richard, using the cfg info actually deals
with this problem without any special code (there would be two edges
out of the block with the "tail" call -- one to the function exit, 
another to the EH handler.  If we have two out edges, then we never
do a tail call optimization.

  > Is there a problem I don't see where if you have
  > 
  > int foo ()  { bar(); }
  > 
  > and bar() throws, you can't just pass the exception up to foo's
  > caller, just as if foo's caller had called bar directly?
I'm not sure enough about EH semantics to know if this situation is even
possible.

If bar can throw, don't we have to assume that foo can throw?  If so, then
no tail call optimization is possible.

  > I was going to say that there would be _fewer_ tail calls in C++, but
  > after a little thought I decided I couldn't be sure; because
  > destructors may very often be tail calls.
Yours is probably a better statement.  And with the nothrow stuff going on
right now there may be some reasonable opportunities for tail call opts
in C++.  I wonder if everything inside an extern "C" block is implicitly
marked as nothrow, which would make calls to those functions potential
tail call sites.

jeff