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
