SSA

[Stephen Weeks]

> I think this is almost working now.  One final subtlety: each continuation
> is given a frame size based on the "high-water mark" on stack slots
> allocated.  This is fine for the continuation, but when we use the
> dominator tree of the intuitive control-flow graph, we might do allocation
> for a cont before all of its paired handlers.  So, when generating the
> continuation stub for a cont/handler pair, we really give it a frame size
> as the maximum of the size of the "real" continuation and the size of the
> paired handler. 

To make sure I understand, I would expect the liveFrame and cont field
of Info.t in allocate-registers.sig to change from

		     liveFrame: Machine.Operand.t list,
		     cont: {size: int} option,

to

		     conts: {handler: Ssa.Label.t option,
			     live: Machine.Operand.t list,
			     size: int} list

to represent the size and live info of each cont-handler stub.

> Note, this complicates any future work on avoiding the stub shuffle with
> non-tail calls; the "real" continuation's arguments may not be allocated
> at the top of the stub's frame.

Does my proposal above fix this?

> This also slightly complicates allocate-registers.  When allocating
> registers for a continuation, we can't compute all of the operands live in
> all the frames, because allocation for some paired handlers might not yet
> have occured.  So, we keep a todo list of thunks to "finish" setting the
> AllocateRegister.Info.T for continuations after allocating all blocks.  We
> don't need to thunk everything, just continuations.

It makes sense to me that one would need to set the sizes of all of
the stubs after all of the allocation is done.

> I'm currently trying to track down a bug in prodcons.sml.  Very strange;
> only shows up when running the regressions script and seems to be related
> to the new removeUnused pass for ssa.

Make sure it's not the same limit check bug :-).  Try running with big
heaps.