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