[LLVMdev] nonlocal go to -- how?

[Mike Stump]

On May 4, 2008, at 9:05 AM, Hendrik Boom wrote:
> The languages I'm faced with compiling in the near future have  
> nonlocal goto statements and nested procedures.

You want to return to a previous activation record (pascal speak) or  
stack frame?  If yes, then yes, EH will do that for you.  You'll want  
to understand what EH is in detail and how to map the semantics you  
want onto it.  That mapping could be simple (if you match the usual  
and customary EH semantics) or complex (if you want to stray farther  
away).  You'll want to understand how you want other languages to  
behave if you have the ability to have other languages on the stack.

For example, Objective-C on Apple's platform currently doesn't  
interoperate very well when C++ is on the stack (imagine an Objective- 
C runtime that uses setjmp/longjmp that bypasses the running of C++  
dtors for stack variables as you throw past them).  This setup, I'd  
claim is unfortunate, and you really want to avoid it.  It is better  
to map whatever semantics you want onto the normal platform EH abi, so  
that other languages, C++ included, just work.

Also, if you do it that way, you should be able to count on the  
optimizer getting rid of all the extra stuff and making the code  
`fast' in more trivial cases.

> The problem is with the go to statement.  Again, local go to's, that  
> go
> somewhere within the same function are no particular problem --  
> though I
> haven't studied the interaction with alloca yet; that might offer a  
> few
> surprises.

The semantics you generally want are all stack allocated variables are  
destroyed as the frame which contained them is destroyed.  Behavior  
other than this would be weird.  A special exception is made for the  
object being thrown and all the data that goes with it.

> The questions I have are about goto's that exit from a
> function.  The traditional mechanism is to implement a label as an
> instruction-pointer/environment-pointer pair, just as for procedures.
> You just load the environment-pointer into the appropriate register,  
> and
> jump to the address.

Additionally, one generally needs to deallocate stack variables as well.

> I don't see a mechanism for this.

See llvm-g++ and C++.  I believe that it works.

> The closest I see is the mechanism for exceptions.  I cannot tell by
> reading the documentation for exception-handling whether it is
> sufficiently flexible to accomodate nonlocal goto's.

It is.

> What's not clear is whether the exception handling mechanism is  
> sufficiently dynamic to
> permit an accurate specification of the jump target.

It is.

> It's not necessarily the most local version of the label on the  
> stack that's the
> target; it's the one whose stack frame is reached by the jumping
> procedure's array of static links.

You're allowed an arbitrary predicate that explains if this is the  
right place to wind up.