Denis Chertykov schrieb: > 2011/3/16 Georg-Johann Lay <a...@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.
I ran tests against svn 170942 (latest 4.7.0 snapshot). Besides timestamps, the diff looks like this: 1435a1436,1437 > XPASS: gcc.dg/sibcall-3.c execution test > XPASS: gcc.dg/sibcall-4.c execution test 1630,1631c1632,1633 < # of unexpected successes 4 < # of expected failures 132 --- > # of unexpected successes 6 > # of expected failures 130 1670c1672 This is due to xfail for runtime-test of sibcall abilities for avr-*-*. Johann
