[MLton] question on closure-convert.fun

[Stephen Weeks]

> In the Accum.done function of closure-convert.fun, there is a call to the 
> SSA shrinker.  The comment there is ancient (from before the death of 
> the CPS IL).

Yeah, although NoDelete is gone, I think the comment is still pretty
much accurate -- you don't want to delete globals while shrinking,
since you're not really looking at the whole program and don't know
which can be safely deleted.

> I was experimenting with dropping optional optimization passes, and
> I've been able to trigger the "shrinker didn't simplify right"
> error.

I.E. a global variable got deleted and shouldn't have.

> Tracing the shrinker at that point reveals that it is doing 
> something along the lines of the following:
..
> which is acceptable behavior for the shrinker.  I don't know if the old 
> CPS shrinker's NoDelete form referenced in the comment would have 
> prevented this form of rewriting.

I bet so.

> Probably the thing to do is to Vector.map2 against the tuple
> returned by the shrinker and the expected variables, adding the
> appropriate Var = Var global statements.

Makes sense.

> These extraneous assignments will be killed off by the removeUnused
> pass if they are truly unused in the rest of the program.

If you add the assignments as global statements in the argument to
Ssa.shrinkFucntion, won't they just not appear in the output
(i.e. "blocks")?