[MLton] question on closure-convert.fun
Matthew Fluet
fluet@cs.cornell.edu
Sun, 19 Jun 2005 21:23:12 -0400 (EDT)
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). I was experimenting with dropping optional optimization
passes, and I've been able to trigger the "shrinker didn't simplify right"
error. Tracing the shrinker at that point reveals that it is doing
something along the lines of the following:
fun F_0 (): {raises = None, returns = None} = L_8906 ()
L_8906 ()
...
x_13339: unit = ()
x_13338: unit ref = Ref_ref(unit) (x_13339)
exnRef_35: unit ref = x_13338
x_13337: exn = Bind_0 (exnRef_35)
x_13336: exn = x_13337
...
x_12660: unit = (...,
x_13339,
x_13338,
exnRef_35,
x_13337,
x_13336,
...)
return x_12660
==>
fun F_0 (): {raises = None, returns = None} = L_8906 ()
L_8906 ()
...
x_13339: unit = ()
x_13338: unit ref = Ref_ref(unit) (x_13339)
x_13337: exn = Bind_0 (x_13338)
...
x_12660: unit = (...,
x_13339,
x_13338,
x_13338,
x_13337,
x_13337,
...)
return x_12660
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.
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. These extraneous assignments will be killed off by the
removeUnused pass if they are truly unused in the rest of the program.