localRef vs. loopInvariant pass ordering

[Matthew Fluet]

> In  the  logs you (Matthew?) say that the localRef pass should definitely run
> after the loopInvariant because more will be handled since  the  ref's  might
> not be passed around afterwards.  That makes sense, but are you sure that the
> extra args introduced (to carry values that used to  be  in  the  ref  cells)
> won't be candidates for loop-invariant hoisting?  If so then there would be a
> gain to running a loopInvariant pass after localRef.

I thought about this.  The original incarnation (I may not have even
checked that one in), that passed the ref around in args in all blocks
dominated by the ref creation would definitely need it, modulo what the
shrinker could figure out.  In particular, the "toplevel handler" ref
would appear in every loop of main.

But, I think that what is currently checked in (ie., that computes a fixed
point on the flow/updates of localizable refs) will not introduce loop
invariant arguments.   I would expect the SSA restore pass to have the
same property.

> By  the  way,  really  impressive  to  see  the  compiler  figure  out   that
> MLton.Random.rand  was  only  called  once  and must return an even value and
> hence knew that one of the functions was dead code.

Yeah.  After running local ref on that example and looking at the output,
I initially thought the pass had some bug in it; but, after investigating
a little, it made sense.