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.