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][AVR]: Support tail calls


Richard Henderson schrieb:
On 03/16/2011 03:32 AM, Georg-Johann Lay wrote:

Richard Henderson schrieb:

On 03/11/2011 05:43 AM, Georg-Johann Lay wrote:

I did not find a way to make this work together with -mcall-prologues.
Please let me know if you have suggestion on how call prologues can be
combine with tail calls.

You need a new symbol in libgcc for this. It should be easy enough to have the sibcall epilogue load up Z+EIND before jumping to the new symbol (perhaps called __sibcall_restores__). This new symbol would be just like the existing __epilogue_restores__ except that it would finish with an eijmp/ijmp instruction (depending on multilib) instead of a ret instruction.

The point is that the intent of -mprologue-saves is to save program memory space (flash). If we load the callee's address in the epilogue, the epilogue's size will increase. Moreover, adding an other lengthy function besides __epilogue_restores__ to libgcc, that will increase code size because in many cases we will see both epilogue flavors being dragged into application.

All true, but supposing there are enough tail calls then on balance you'll still save flash space.

Only if epilogue size decreses. As tail-call saves at most 2 bytes and storing the address (either return-to in epilogue or jump-to caller) will take more than 2 bytes. So nothing is won.


An intermediate alternative is to simply override TARGET_CALL_PROLOGUES
in sibcall epilogues. I.e. let __prologue_saves__ be generated as usual,
and __epilogue_restores__ be generated as usual for normal epilogues, but test for sibcall_p in computing "minimize".

This means that long epilogues that with call-prologues would deflate then would no more deflate and had to be coded inline in epilogue.


Maybe we can take the patch as-is, let approve it and fiddle out more optimization opportunities later?

Johann


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