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

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 10-Sep-2002, Andreas Bauer <baueran@in.tum.de> wrote:
> The reason why I chose a new and independent call sequence is that I am
> aiming to optimise indirect calls as well (and maybe few other
> constraints I encounter during this process).  Indirect calls, as you
> have pointed out in an earlier email, can not easily be optimised on
> certain platforms as the call clobbers all registers on register poor
> machines.  Super sib calls will therefore not work on these architectures

I don't see why you would want to disable *all* super sib calls on such
platforms; it would be better to disable the use of super sib calls
only for those cases that won't work.  In particular it should be
possible to use super sib calls for direct calls.

> and it may be useful to have the original sibcall framework as a fall
> back, IMO.

By all means keep the original sib call code as a fall back.
But the decision as to whether to use the original sib call code
or the new super sib call code can be done in calls.c, when
generating the call, rather than in sibcall.c.

(Actually the new super sib call code should be the fall back, and the
original sib call code should be tried first, since in cases where
both are applicable, the original sib call code will be more efficient.)

> So, maybe it would be more appropriate redesigning the sibcall stuff and
> simply add my argument marshalling mechanism to it, but I do not see how
> I could possibly address indirect calls without making ARM maintainers
> (and others) unhappy.

This could be achieved by only optimizing indirect calls in cases
where it is safe to do so.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.