Re: forcing tail/sibling call optimization

[Jeffrey A Law <law@redhat.com>]

  In message < 20001127164400.0929334D80@nile.gnat.com >you write:
  > <<Therein lies the first problem -- programmer dependence on specific
  > optimizations in the compiler.  That's a fundamental mistake.
  > >>
  > 
  > I think this misses the point, this is not just an optimization, it is
  > a fundamental functional capability, in other words, we would want the
  > compiler to do this EVEN IF it slowed down execution.
I don't care if slows down or speeds up execution -- dependence on this kind
of transformation in languages such as C is terribly bad.  C code which
relies on this transformation is broken.

About the only thing worse would be to sit down, examine the compiler's output
to see when it makes the transformation, then twiddle the code to make it
compiler friendly, then complain when the next rev of the compiler doesn't
behave in the same manner :-)

In contrast, dependence on this kind of transformation in other languages
might be quite reasonable (and I believe there are languages which explicitly
require these transformations).  Typically those languages have conventions
which significantly ease these kinds of transformations.

We're apparently not communicating well.  


  > difference between an optimization that simply saves some time, and
  > a fundamental transformation that changes the computational nature
  > of the program. Changing the amount of storage used from O(who knows
  > what) to O(1) is not simply an "optimization".
Optimizations can occur across several axis -- execution speed, code density,
stack space, etc etc etc.  This transformation is an optimization in stack
space and sometimes code speed.

jeff