"root" of ChunkPerFunc chunk

[Stephen Weeks]

> I'm fairly sure that the Temp is necessary (in the sense that it will
> force the destination of the add to be a register), because something like
> 
> SI(4) = Int_addCheck(Y, Z)
> 
> shouldn't write an overflow value to SI(4), because the original value of
> SI(4) might be needed by the overflow handler.  (Is this correct? 

Yes.  It seems to me that a reasonable semantics for the machine IL would allow
the overflow label to have SI(4) live.  For example, the following CPS code code 
could allocate x and y to SI(4).

   val x = ...
   fun L() = ... x ...
   val y = x + 1

I don't think it ever happens with the current register allocator, but I don't
think it's worth taking advantage of, especially since you have explicit
liveness info.

> I spent
> some time trying to determine what optimizations could occur "through" an
> overflow checking primitive, and I decided that there really aren't any,
> at least that correspond to the optimizations already in the simplifier.)

I'm not quite sure what you mean here.  The semantics of a checking primitive
are to do the arithmetic op and to jump to the label immediately if there was an 
overflow.  So, in the case of overflow, any side effects before the primitive
must happen and any after must not happen.

> So, it would seem I need a better ordering for the processing of blocks.
> Topological sort would seem to do the trick, but I need one (or more)
> roots.  And, after writing all this, I realized I do in fact have those
> roots: they are the labels in the exports field of a Chunk.

Just wanted to point out that topsort is available in
	src/lib/mlton/directed-graph/directed-graph.sig

> So, probably largely ignore this, although I'd be interested in feedback
> about what possible optimizations could be done to checking prims.  I
> don't think this far into the backend is the appropriate place to try to
> determine when a checking prim can be replaced by a non-checking prim;

Agreed.

> although I do one very special case:
> Int_add(0, X), Int_add(X, 0), Int_sub(X, 0) -> drop the overflow check
> Int_sub(0, X) -> Int_neg(X), but leave the overflow check
> and I guess I could also do
> Int_mul(1, X), Int_mul(X, 1), Int_mul(~1, X), Int_mul(X, ~1)

These should definitely be done (but aren't right now) by the CPS shrinker.