new SSA IL

[Stephen Weeks]

> In  the new SSA form, are variables mutable? 

No.

> I guess that with the initial S
> of SSA they are not.  How, in that world, do you  express  something  like  a
> loop.   (I.e., computing the length of a list with a tail-recursive routine.)

Gotos still pass arguments, just like jumps in the old world.  So there are
still tail recursive loops of basic blocks just like before.  There is just no
lexical scoping.

> Where is the extra generality really?   Is  it  that  blocks  don't  have  to
> properly nest?

Yes.  The generality comes from replacing lexical scoping conditions by
dominator conditions.  I think the dominator stuff can be mimicked in the
current world by rewriting the syntax trees, but it just doesn't seem worth it
to me to go down that route.

Oh, and I think I forgot to mention the extra generality of mutually recursive
continuations, which we didn't have in the old world, but faked very well (in
the contification transformation).

> Isn't    the    only    difference    between    HandlerPush/HandlerPop   and
> RestoreExnStack/SaveExnStack that it does blocks of pushes and  pops?   I.e.,
> can you use RestoreExnStack to push things on the exception stack?

RestoreExnStack/SaveExnStack only deal with the link in the current stack frame
and the global (er, per thread) exnStack pointer.  They have exactly the same
semantics as the C macros in ccodegen.h.  SetHandler stores a label in the
current stack frame.  The idea is that the link operations are decoupled from
the label operations, so that we can express optimizations that set one but not
the other.  Currently, the backend translates HandlerPush and Pop as follows.

HandlerPush l = 
	if previous exn stack is empty 
           then SaveExnStack
        else ();
	SetHandler l
HandlerPop l =
 	if exn stack will be empty
           then RestoreExnStack
        else SetHandler l'  (where l' is the top of the new exn stack)

There are lots of optimizations to this approach that cannot be expressed with
handler push and pop.  For example, we might want to set the link before some
if-branch because we know that down both branches a handler will be installed,
but we may not know which handler until after the if.

> I  know  you  guys are busy putting in new optimizations (which is very good)
> but I really wish that there were an up-to-date analogue of the  old  hackers
> guide.   I  really  feel lost these days when I look at the compiler sources.
> (My own fault, I know.)

Yeah, it doesn't seem a good use of time right now.  Maybe once we get the CVS
up and if lots of people start hacking it will be.