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....