[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.