This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 05/26/14 14:32, Kai Tietz wrote:
----- 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.
But the value we want may be sitting around in a convenient register (such as r11). So if we force the sibcall to use %rax, then we have to generate a copy. Yet if we have a constraint for the set of registers allowed here, then we give the register allocator the opportunity to coalesce away the copies.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]