Re: What should finish do?

[Jeffrey A Law <law at cygnus dot com>]

  In message <200005031548.IAA23286@cygnus.com>you write:
  > "Peter.Schauer" wrote:
  > > 
  > > > As I see it, there are two sensible options:
  > > >
  > > >     1) "finish" should finish executing the current function and cause
  > > >        execution to stop when control is returned to the caller (at the
  > > >        earliest point).
  > > >
  > > >     2) "finish" should finish executing the current function and cause
  > > >        execution to stop when control is returned to the caller, but
  > > >        after whatever (architecture specific, perhaps even compiler
  > > >        specific) instructions are used to restore the caller-save
  > > >        registers.
  > > >
  > > > Note that stopping at the next line is not a sensible option because
  > > > if you finish out of g() in f(g()), it is an error to stop execution
  > > > at the next line.  I.e, you want to have the opportunity to step into
  > > > f().
  > > 
  > > And we are interested in the return value of g(), which might already
  > > be clobbered if we stop in the next line.
  > > I'd favor 2) as well, but I suspect that it will add extra hair for some
  > > targets.
  > 
  > It will definitly be hard (once -O is applied).  Compilers like to
  > forget to cleanup stack frames so walking the unwind instructions could
  > end up as hairy as the code that skips the prologue.
Right.  At the current time scheduling could mix the restores of the
call-clobbered registers with user code, though you'll never have to
scan further than the next branch to find the restores.

However, it is likely in the future that GCC will have the capability of
moving call-clobbered register restores across basic block boundaries
which might make finding them nearly impossible.

Consider the case where we have a function call within a loop.  A variable
which is live across the loop, but which is not used/set in the loop has
been allocated to a call-clobbered register.  Right now we will save/restore
that call-clobbered register around the call site.  However, in the future
it is likely that the save will occur before in the loop pre-header and the
restore will happen on the exit path(s) from the loop.  

[ Yes, this would be a lame register allocation, but it can happen in some
  cases.  ]
jeff