This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: forcing tail/sibling call optimization



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.

-tim

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]