[patch i386]: Expand sibling-tail-calls via accumulator register

[Kai Tietz]

----- Original Message -----
> On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote:
> > > In any case, I still can't understand how limiting the choices of the
> > > register allocator can improve code rather than making it worse.
> > > If the accumulator is available there, why doesn't the RA choose it
> > > if it is beneficial?  And why aren't other registers similarly suitable
> > > for
> > > that?  Say r10, r11...
> > 
> > I don't see it as limiting.  The intend of this is more to have fixed
> > patterns on epilogue.  And in fact is accumulator that register which can
> > be used as scratch-register for all i386-targets.  Beside for
> > varardic-functions, which anyway aren't any good candidates for
> > sibling-call-optimization (on x86_64 due ABI).  Well, for x86_64 ABI we
> > might could consider to use R11_REG instead of AX_REG.  Is there any
> > advantage in special-case for x86_64 ABI?  The R10-register isn't a good
> > choice due it might be used as drap-register and therefore can't be loaded
> > before epilogue gets destroyed.
> 
> It is limiting.  If r11/rax and often also r10 can be chosen, telling the RA
> it can only choose rax is a limitation.

No, it isn't.  For sure.  The code-branch choosing the accu to call after epilogue isn't used as memories for sibling-calls aren't allowed.  This code-branch will get active with my other sibling-tail-call patch.
 
> Can you show some testcase where your patch is actually beneficial?  We
> should analyze why the RA made that choice.

So it is obvious I can't provide you samples you asked for.  Nevertheless I am pretty interested to see a sample by you (with activated sibling-tail-call memories) which chooses for tail-call-register for memory something else then accu.
 
> 	Jakub
> 

Kai