RSSA

[Stephen Weeks]

> I'm fighting the CCall / CReturn distinction more than I'd like to.  In
> particular, is there a strong reason to put the dst in the CReturn rather
> than in the CCall?  For example, the Arith transfer has the dst in
> transfer, rather than in return location.  I'd prefer to go with
> eliminating the CReturn kind (or at least making it nullary) in Machine 
> and go with:
> 
>      | CCall of {args: Operand.t vector,
>                  dst: (Operand.t * Size.t) option,
> 		 prim: Prim.t,
> 		 return: Label.t (* must be nullary *)}

The reason that Arith has the dst in the transfer is because the
result is stored in dst before the transfer happens.  Hence, the dst
is live in the return.  OTOH, in a CCall, the result is not stored
until after returning from the call.  Hence the dst is not live in the
return.  Moving the dst to the transfer would get the liveness wrong,
and doesn't correspond to my intuitions of when the variable is
stored.  Could you explain in more detail the problems?

> Why isn't the stack check for limit checks completely orthogonal to the
> array/heap distinction?  An SSA function which begins with a variable
> array allocation should be able to get by with one limit check for both
> the array and the stack.

Agreed.  Should we add stackToo to the Array constructor?

> More questions on Arrays and limit checks: is there is bug in the
> c-codegen's implementation of array limit checks:
> 
> 			 in case limitCheck
> 			    of NONE => ()
> 			     | SOME {gcInfo, bytesPerElt, bytesAllocated} 
> 			       => let
> 				     val bytes =
> 					concat [numElts, 
> 						" * ", C.int bytesPerElt, 
> 						" + ", 
> 						C.int bytesAllocated];
> 				  in
> 				     GCInfo.outputLimitCheck (gcInfo, bytes,
> 							     false, print);
> 				     print "\t"
> 				  end;
> 
> Don't we need at least two more bytes for the header and the length?  And,
> in the case numElts = 0, we need one byte for the forwarding pointer.
> I'm happy enough just adding 3 to every array allocation limit check, even
> though that might request one more byte than is strictly necessary.

In limit check insertion, that was (and will be) handled by adding to
the bytesAllocated field, so the codegens don't need to do anything.
Actually, the right amount to add is 3 words = 12 bytes.  And of
course, LIMIT_SLOP comes in to play as always -- and will be handled
by limit check insertion.