This is the mail archive of the gcc-patches@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]

Re: tail call optimizations



  In message <200003201213.MAA06246@cam-mail2.cambridge.arm.com>you write:
  > 1) calls.c makes reference to md patterns sibcall, sibcall_value, 
  > sibcall_pop, sibcall_value_pop and sibcall_epilogue.  Only the last of 
  > these has any documentation in md.texi.  What do the others do?  What form 
  > do they take?
They're just like normal calls in terms of arguments and such.  I'll try to
crib up a patch to md.texi for this (I thought I had one, but apparently
not).

  > 2) Can I assume that the compiler proper will not try to make a sibcall if 
  > the function might be passed the address of something in the current frame 
  > (eg address of a local variable, result of alloca())?
Correct.  Though the detection of this could be significantly improved.


  > 3) md.texi says
  > 
  >   "The @code{sibcall_epilogue} pattern must not clobber any arguments used
  >   for parameter passing or any stack slots for arguments passed to the
  >   current function."
  > 
  > Maybe I've missed the point here, but how can I be sure that I won't do 
  > the latter?  After all, the stack frame has to unwound by the epilogue 
  > instructions.
It removes the *current* function's frame, but the arguments were set up by
the caller into space allocated by the caller, so that's not a problem.


  > PS.  You, or was it Mark, said that some of the code would probably go 
  > when we moved to a tree-based implementation.  Will that still work with 
  > tail-calling libcalls?  (For that matter, does the current implementation 
  > work with libcalls?)
Not sure if it works with libcalls.  Good question.


jeff


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