Re: __attribute__((cleanup(function)) versus try/finally

[Geoff Keating <geoffk@geoffk.org>]

Mike Stump <mrs@apple.com> writes:

> On Thursday, May 8, 2003, at 01:46 PM, Richard Henderson wrote:
> > On Thu, May 08, 2003 at 11:29:50AM -0700, Mike Stump wrote:
> >> If table size is a big issue, we can have C default to sjlj EH (lower
> >> cost in non-EH code), and integrate in handling for sjlj exceptions
> >> into the dwarf EH system.
> >
> > Lets not, please.  This is much harder than you realize, and
> > involves a siginificant performance impact to dwarf-only EH.
> 
> Ok.  I was imagining a scheme that elaborated a failure case (lookup
> the pc and not find any entries) and just checked the new sp value
> against sjlh_EH_stack->sp and did the sjlj stack processing if
> required.  Maybe there are other nits that complicate it.

If table size is an issue, how about we just reduce it?

For instance, much of the information in the tables is included in the
object code (nearly all of it in the case of routines that don't
actually have cleanups).  It wouldn't be that hard to write a routine
that, given a return address, can determine what registers need to be
restored and from where in 90% of the cases by looking at the object
code; those routines (in the 90%) can have an abbreviated EH entry
that just says "use the object code", and the remaining 10% could have
a real EH entry.

For powerpc-elf, this could be as simple as this algorithm:

1. Look back in the object code until you see a stack push
2. That stack push creates the initial frame, so you know the size of the frame
2. Look forward from here until you see a branch
   3a. For the first store of each callee-saved register at an offset from
       the stack (maybe with some special code for altivec), restore it
       from that offset.

Now, this doesn't work in every case; routines with a too-large stack
frame, or that use alloca, won't work, and you won't want to try this
with any routine that's larger than a certain size for efficiency
reasons, and there may be other cases.  But it does work for the vast
majority of routines, and it's easy to check (given some RTL) whether
it'll work, and that's enough.

For x86, you'll want something a bit more complicated, because you'll
want to track push/pop operations, but if you can find the start of
the routine, you can follow code flow and assume that the stack depth
is constant at any particular point to avoid needing to go around
loops (like the Java verifier).

-- 
- Geoffrey Keating <geoffk@geoffk.org>