This is the mail archive of the
mailing list for the GCC project.
Re: forcing tail/sibling call optimization
- To: dewar at gnat dot com (Robert Dewar)
- Subject: Re: forcing tail/sibling call optimization
- From: "Timothy J. Wood" <tjw at omnigroup dot com>
- Date: Sun, 26 Nov 2000 10:59:01 -0800
- Cc: fjh at cs dot mu dot oz dot au, gcc at gcc dot gnu dot org
- Reply-To: tjw at omnigroup dot com
On Sunday, November 26, 2000, at 08:14 AM, Robert Dewar wrote:
>The formal definition seems quite reasonable here, but I must say
>I dislike the syntax, and it is unnecessarily provocative, since
>this really is not semantically a goto at all (e.g. the formal
>denmotational semantics would have nothing to do with the semantics
>of goto). Why not something like "tail return" or perhaps better
>simply a compiler directive.
This would introduce a new reserved word, wouldn't it? This would break existing source code that used 'tail' as a variable, class, etc.
It seems like rather than telling the compiler to just blindly do a tail return even though a function takes a pointer that it could conceivably store, a 'better' solution would be to add a attribute that could be applied to arguments to specify that the function doesn't hold onto that pointer. The compiler would then have enough information to decide when it could do a tail call and the compiler could potentially _enforce_ the restriction that the argument cannot be stored anywhere but in a location that is provably part of a stack local.
The only thing this wouldn't do is to give a warning/error when the developer knows that a tail call must occur to prevent bugs (like stack overflow), but it seems like adding an attribute to the arguments would prevent errors due to someone providing a function that isn't a valid tail call target.