Prim.entersRuntime vs Prim.runtimeTransfer

[Stephen Weeks]

I don't completely understand the reasoning behind why the particular
subset of Prim.entersRuntime primitives was chosen for
Prim.runtimeTransfer.  Here are how they are used in MLton.

entersRuntime is used by

* liveness analysis to associate a list of live vars at a primapp that
  enters runtime  
* register allocation to force those lives into stack slots
* the C backend to put the approiate arguments for the InvokeRuntime macro

runtimeTransfer is used by 

* closure converter to split blocks at primapps that enter the runtime
  and "have a control-flow feel"

Here are the definitions 

      val entersRuntime =
	 fn Array_array => true
	  | Array_array0 => true
	  | GC_collect => true
	  | MLton_deserialize => true
	  | MLton_halt => true
	  | MLton_serialize => true
	  | Thread_copy => true
	  | Thread_copyCurrent => true
	  | Thread_finishHandler => true
	  | Thread_switchTo => true
	  | World_save => true
	  | _ => false

      val runtimeTransfer =
	 fn MLton_halt => true
	  | Thread_copyCurrent => true
	  | Thread_switchTo => true
	  | World_save => true
	  | _ => false

Ignoring deserialize and serialize, which are unused, here are the
additional prims that are entersRuntime but not runtimeTransfer

	Array_array
	Array_array0
	GC_collect
	Thread_copy
	Thread_finishHandler

I'm not sure why we need both of these notions, so I propose to
combine the two notions into one, called entersRuntime, by eliminating
the Array prims.  It seems to me that the other three (GC_collect,
Thread_copy, Thread_finishHandler) are reasonable places to split
blocks because the runtime is certainly entered at them.  The array
prims will be handled separately by the new RSSA/limit check stuff,
which will split blocks so that arrays are at the beginning of a
block.