This is the mail archive of the gcc@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: Leaf functions and noreturn calls


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


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