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