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


2011/3/16 Georg-Johann Lay <avr@gjlay.de>
>
> 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?

Is it tested forÂregressions ?

Denis.


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