On 21 March 2006 14:59, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 04:19:52PM -0000, Dave Korn wrote:
>> However, I might still want to make it an option for cases where debugging
>> isn't going to be important; it seems to me that the generated code should
>> still be valid.
>
> At which point you should tail call to abort and be done with it.
> So the correct change is to the tail call code, which currently
> filters out noreturn functions.
Ok, seems reasonable. I see code in calls.c that checks for the noreturn
flag and clears try_tail_call if so, so I'll need to fix that. I'm wondering
if that'd be enough on its own though, because I don't see why this chunk of
code from sibcall.c...
if (no_sibcalls_this_function
/* ??? Overly conservative. */
|| frame_offset
/* Any function that calls setjmp might have longjmp called from
any called function. ??? We really should represent this
properly in the CFG so that this needn't be special cased.
*/
|| current_function_calls_setjmp
/* Can't if more than one successor or single successor is not
exit block. These two tests prevent tail call optimization
in the presense of active exception handlers. */
|| call_block->succ == NULL
|| call_block->succ->succ_next != NULL
|| (call_block->succ->dest != EXIT_BLOCK_PTR
&& call_block->succ->dest != alternate_exit)
/* If this call doesn't end the block, there are operations at
the end of the block which we must execute after returning.
*/
|| ! call_ends_block_p (insn, call_block->end))
sibcall = 0, tailrecursion = 0;
.. wouldn't check the succ block of the noreturn call and forbid the sibcall
if it wasn't at the end of the enclosing function.
I may also have to improve my call/call_value patterns. At the moment they
just test SIBLING_CALL_P and emit a non-linking jump if so, but that means
they still have a clobber of LR attached which is no longer the case and
that's likely to force my functions to still have stackframes unnecessarily.
Looking at the ARM md-file as an example, it seems that I can use expanders
to match them.
And looking at call.c, it seems there are perhaps some undocumented (in
3.3.3) named patterns that provide a sib- equivalent for each of the normal
call_xxxxx patterns? Ow, that's a little tricky!
cheers,
DaveK
--
Can't think of a witty .sigline today....
