new SSA IL
Tue, 7 Aug 2001 21:57:44 -0700
> 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 =
> 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)
> 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.