contification

Matthew Fluet Matthew Fluet <fluet@CS.Cornell.EDU>
Wed, 24 Oct 2001 11:17:34 -0400 (EDT)


Just so nobody thinks that the SSA IL is all doom and gloom, liveness and
limit checks, I ported contification from CPS to SSA in about half an
afternoon.  It's much nicer than in CPS; the Transform code is about half
the size that it used to be.  No major issues with porting; continuations
are cont/handler pairs for the purposes of "one return point".  I ran
through all of the regressions with -drop-pass contify{1,2,3}, so
everything seems to be in order.  I'm leaving it disabled in SSA simplify
for right now; it won't do much of anything with the three passes already
running in CPS simplify. 

That being said, here are the problems: ;)  

1. lack of a shinker that eliminates unused blocks can leave a program
that is well formed, but the control-flow graph isn't connected, so the
type-checker fails when it tries to compute the dominators for
checkScopes.  (For example, contifying a leaf function which does not
raise at a non-tail call with a handler can leave the handler uncalled.)
No huge deal; removeUnused running immediately after it cleans them up. 
Just means that compiling with -type-check true will sometimes fail.

2. I get some problems with the invariant check in the GC when compiling
with -g.  It's a handler stack "problem".  What seems to be happening is
that the Set* statements in the contified function aren't being changed in
any way (I don't touch the statements at all; just rewrite transfers).  I
can end up with a situation where the main_0 function ends up with it's
link slot pointing to itself.  Then the loop that walks the exnStack in
the invariant check get's stuck.  I get no runtime errors; I think, to an
extent, this is o.k.  It just corresponds to the link slot being in an
undefined state at a place in the execution when we won't need it.