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

[Andreas Bauer <baueran at in dot tum dot de>]

> Personally, I see this as the _easy_ part.  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.

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
and it may be useful to have the original sibcall framework as a fall
back, IMO.

As I have explained in my first email, the goal of these optimisations is
to enable certain front-ends to do tail call optimisation.  And, for
example, the GHC generated intermediate C-code has got indirect calls all
over the place.

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.

Andi.