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

[Jason Ozolins <jason dot ozolins at anu dot edu dot au>]

Simon Marlow wrote:

> > 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.

Doing the dependency analysis would be great, but it strikes me that if
it were easy, someone would probably already have done it.  :-)  If it
is the case that it's not done at all because it's hard to make it
perfect, what's wrong with an effort to make tail-calls work with
overlapping arguments in a way that is easier to verify correctness,
leaving open the option to do the dependency analysis as an optimization
later on?  If the tail-call must be annotated in the source to be a
candidate for super sibcalling, as was mentioned by Markus Pizka, then
the only people who pay the price for argument rearrangement are people
who explicitly request a tailcall; they can decide whether to pay the
time penalty for argument rearrangement in return for constraining stack
usage.

In the worst case you may well need N temporaries anyway, so you do need
to decide where to put the "argument marshalling area" for the
super-sibcall; consider

int foo (int a, b, c, d)
{
	return bar (a*2+b*3+c*5+d*7, a*3+b*5+c*7+d*11,
			a*5+b*7+c*11+d*13, a*7+b*11+c*13+d*17);
}

It may be possible to do this with less than 4 temporaries, but I don't
think it's easy.  If the multipliers aren't literal values but globals,
then it gets close to impossible, no?  In light of this, I reckon that
getting overlapping arguments working at all would be better than
waiting for the perfect solution to argument rearrangement.
-- 
Jason Ozolins
Technical Support Group                 Local: x55449
Department of Computer Science         Global: +61 2 6125 5449          
The Australian National University      Email: jason.ozolins@anu.edu.au