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


Mark Probst <schani@mips.complang.tuwien.ac.at> 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

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