new SSA IL

[Stephen Weeks]

> But  in  the function call case, I understand that it is a different binding.
> In the SSA case, I can't do that, since all the  variables  look  global  but
> initially  un-initialized.

You can give exactly the same semantics (rebinding) in the SSA case.  The point
is, that because it's a tail call, none of the old values matter, so rebinding =
assignment.

>  Even  that  sounds pretty imperative.  I guess I
> don't see how to think of continuation calling.  In straight  SSA,  there  is
> just a phi-function assignment to the args.  In your SSA I see an assignment.
> I seem to have to think of it more imperatively  because  of  the  fact  that
> there are `other' assignments at other call sites.  (Of course these are part
> of the call-ee, not call-er, so they really are the same site.)

In our variant

fun f (x, y) = ...
fun g ... = ... f (a, b) ...
fun h ... = ... f (c, d) ...

In straight SSA

f:	x <- phi (a, c)
 	y <- phi (b, d)
	...
g:	... 
	goto f
	...
h:	... 
	goto f 
	...

> I see, the point is that when  you  transform  the  code  in  some  way,  the
> dominator tree doesn't change much, but maintaining the block structure would
> require more surgery, correct?

Further, we're not even gonna maintain the dominator tree.  We're going to
recompute it when we need it (for an analysis or typechecking).  That way, all
of the "work" goes into the proof of correctness of a given transformation and
not into compile-time data structure maintenance.

> As to the guide, the main thing that I need (I think) is an overview  of  the
> compiler.  When ever I try to look at it I find myself lost.  Part of this is
> your highly structure-ized style.  I'm not arguing against it,  just  that  I
> don't understand how to navigate in it.  I keep seeing big .cm files and have
> no idea how to find a definition given a use.  Any commentary would be great,
> including any summary of your style of functor/structure/signature stuff.

OK.  It's on the todo.