From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjstein@bfr.co.il (Harvey J. Stein) To: Mark Probst Cc: gcc@gcc.gnu.org, Jeffrey A Law Subject: Re: forcing tail/sibling call optimization Date: Mon, 27 Nov 2000 14:42:00 -0000 Message-id: References: <20001127164400.0929334D80@nile.gnat.com> <490.975347114@upchuck> <20001127192214.Q16207@vader.unix.cslab.tuwien.ac.at> X-SW-Source: 2000-11/msg01212.html Mark Probst writes: > On Mon, Nov 27, 2000 at 10:45:14AM -0700, Jeffrey A Law wrote: > > 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. > > as has been pointed out, this kind of transformation cannot be > implemented as a simple optimization since it requires a different > calling convention. hence, it can only be implemented as a gnu > extension to the c language. as such, it is as legitimate as nested > functions or label pointers, imho. Except that this extension already exists - functions can already have the __stdcall__ attribute, and gcc can be called with the -mrtd switch. I think that's all the calling convention support that's necessary. The only thing new that's needed in the compiler is special treatment of return(g(...)) when it occurs in a __stdcall__ function and g is a __stdcall__ fcn too. More specifically, if f is a __stdcall__ and g is a __stdcall__, then when encountering return(g(...)) inside of f, GCC should compile it to "pop f's stack & args, push g's args, jump to g", instead of "push g's args, call g, pop f's stack, return what g returned". -- Harvey Stein Bloomberg LP hjstein@bfr.co.il