RE: Work in progress: "Super Sib Calls"; opinions sought

["Simon Marlow" <simonmar at microsoft dot com>]

> > This could be done
> > within the existing framework for sibcalls.  And, IMO, if you're
> > not doing this within the existing framework for sibcalls you 
> > are making a mistake.
> 
> In other words, the decision between whether to use an 
> ordinary sibcall
> (construct arguments in the incoming args area) and a "super sibcall"
> (construct arguments in the outgoing args area and then copy them to
> the incoming args area) should be made in calls.c, before constructing
> the sibcall CALL_PLACEHOLDER chain.  OK, that sounds reasonable.

Wouldn't it be better to always contruct the new arguments in place,
using a dependency-analysis pass to decide in which order to calculate
the arguments and whether any temporaries are needed?  In most cases
you'd be able to do a tail-call as fast or faster than a normal call.  

I realise this is much harder than doing the copying, but it's a big win
because it eliminates the performance pessimisation of copying the
arguments, meaning that having tail-calls turned on all the time would
probably be a good idea from a performace perspective, not just stack
space.

> Right.  I think Andreas is not trying to distinguish between 
> these two,
> but is planning to use the explicit annotation approach that I
> posted some time ago.  In other words, we'd distinguish 
> between those and
> 
>  	void quux()
>  	{
>  	  int x[100];
>  	  global = x;
>  	  __tailcall bar(); /* legal to tail-call;
> 	  	the annotation implies that
> 		bar is not allowed to reference x. */
>  	}
> 
> But this can be dealt with by a separate patch.
> It doesn't need to be part of Andreas' change.

Speaking as someone who works on a compiler which generates this kind of
code, I'd be happy with an explicit annotation.  Happier, even: the
compiler can warn me if the call can't be compiled as a tail-call.

Cheers,
	Simon