Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!tektronix!tekcrl!tekchips!stevev
From: stevev@tekchips.TEK.COM (Steve Vegdahl)
Newsgroups: comp.misc
Subject: Re: Tail recursion elimination in [G]CC? (was:Re:Basics of Program Design)
Message-ID: <3358@tekchips.TEK.COM>
Date: 28 Jun 88 17:34:18 GMT
References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <3347@tekchips.TEK.COM> 
Distribution: na
Organization: Tektronix Inc., Beaverton, Or.
Lines: 51

[Discussion of tail-call optimization for the C program:
 strlen (s) char   *s; { return (*s) ? strlen(s+1) + 1 : 0; }]

In article , webber@porthos.rutgers.edu (Bob Webber) writes:
> Over 10 years ago this stuff was being done on lisp compilers.  The first
> step is the generation of a ``helping variable'' creating
>   strlen2(s,n) char *s; int n; { return (*s) ? strlen2(s,1+n) : n ; }
> which is then recognized to be tail recursive. ...

There are lots of transformations that a compiler could conceivably perform,
including the one mentioned above.  Each one will tend to decrease the speed
and increase both the size and expected number of compiler bugs.  The issue
is then a tradeoff between the above issues and the expected gain in
efficiency for the "typical" (whatever that means) program.  The tradeoffs
for a lisp compiler and a C compiler are likely to be quite different.  Even
for a lisp compiler, the optimization mentioned not be near the top of the
list of transformations that I would expect.

> > BTW, does a typical C compiler perform tail-call optimization.
 ...
> Being commercial products, not alot is known about the optimizations actually
> done by the standard compilers.  However, my understanding is that the GNU
> CC compiler is at least as good as what the commerical people are cranking out,
> so to the extent that statistics of 1 case are better than statistics
> of 0 cases, I am cross posting this message over to gnu.gcc to see if any
> of the experts over there know how it would handle such code.

Detecting whether a compiler does tail-call optimization should not be that
difficult: just construct a suitably large test case and see whether the
stack overflows.  I tried the above program with the (VAX) UNIX C compiler.
With a string of length 100, it worked fine; when I upped the size to
100000, it generated a segmentation fault, presumably because it overflowed
the stack.  I also transformed the program by adding the dummy argument,
thereby making it truly tail recursive: same result.  Conclusion: the VAX
UNIX C compiler does not perform tail-call optimization even in the simple
cases.

I think that the statement that "any decent compiler would remove the tail
recursion" is a bit strong, especially considering that additional program
transformation is necessary to put it into tail-recursive form.  How many
production Lisp or Scheme compilers perform this "two-step" optimization?

> p.s., The above code was being discussed in the context of a student compiler
> project and I still maintain that even if it wasn't optimized, that such
> an implementation of strlen is not ``unreasonable.''

I agree.
		Steve Vegdahl
		Computer Research Lab
		Tektronix Labs
		Beaverton, Oregon