new SSA IL
Tue, 7 Aug 2001 20:40:35 -0700
> In the new SSA form, are variables mutable?
> 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
> 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
HandlerPop l =
if exn stack will be empty
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.