[MLton] bug in refFlatten

[Matthew Fluet]

> There appears to be a subtle bug in the refFlatten pass.  The pass seems
> to be sensitive to the ordering of functions in the SSA2 program
> representation.  While it would be o.k. (though, less than ideal) to get
> different results depending on the order of functions, in this situation, 
> the semantics of the resulting program changes.
> 
> The bug is exhibitted by ref-flatten.sml from the regression suite.  To 
> trigger the bug, write a simple SSA2 that simply reverses the order of 
> functions in the program representation.  Run this pass immediately before 
> the refFlatten pass.  The program prints 13 instead of 44.

Ultimately, the bug seems tracable to the fact that in the reversed 
program, refFlatten decides to flatten the second component of the A_0 
constructor.  

In refFlatten.pre.ssa2, we have:

t_0 = A_0 of (word32 * (word32 ref)) | B_0 of (unit)

  L_2863 (x_28843: A_0 of (word32 * (word32 ref)))
    x_28845: word32 = #0 x_28843
    x_28844: (word32 ref) = #1 x_28843
    L_748 (x_28845 + global_9) Overflow => L_2775 ()
  L_748 (x_26177: word32)
    x_28846: A_0 of (word32 * (word32 ref)) = A_0 (x_26177, x_28844)
    x_26178: t_0 = x_28846: t_0
    L_749 (x_26178)


In refFlatten.post.ssa2, we have:

t_0 = A_0 of (word32 * word32 ref) | B_0 of (unit)

  L_2863 (x_28843: A_0 of (word32 * word32 ref))
    x_28845: word32 = #0 x_28843
    L_748 (x_28845 + global_9) Overflow => L_2775 ()
  L_748 (x_26177: word32)
    x_28993: word32 = #1 x_28843
    x_28846: A_0 of (word32 * word32 ref) = A_0 (x_26177, x_28993)
    x_26178: t_0 = x_28846: t_0
    L_749 (x_26178)


This is incorrect, since in the pre program, the reference cell is shared 
between the destructed and constructed A_0 variant, while in the post 
program, the updates to the second component in either the destructed or 
constructed A_0 variant is not seen by the other.  The uses of the t_0 
datatype are spread across multiple SSA2 functions.