latest RPM

[Matthew Fluet]

> > The only place where I make use of Void is in MLton_eq, where two voids
> > are always equal.  If you're confident enough about never propagating back
> > voids to the codegens, we could change the MachineOutput.Operand.t type to
> > reflect that.
> 
> I am confident (I even put an assert in), but I don't want to get rid of void
> for now, since there is a place in backend where I would have to create an
> Operand.t option instead of an Operand.t, and I don't wanna pay that cost.

In backend.fun or in the c-codegen?  What I was suggesting was during the
translation from Machine.Operand.t to MachineOuput.Operand.t we could
eliminate the Void variant.  The backend.fun runs completely on the
machine IL defined in machine.{sig,fun}, but the two codegens run on
machine-output.{sig,fun}.  The translation occurs in main.sml at
      val mprogram = Machine.Program.toMachineOutput machine

As I think about it, we could also set up that translation to do clear any
property lists that you think are still lying around.  It's going to walk
over the whole program anyways.