latest RPM

[Matthew Fluet]

> I looked at that, but unfortunately right now Machine.Operand.t is the same as
> MachineOutput.operand.t (look at machine.fun).  We could do it by duplicating
> the code and paying some copying cost at translation.  I wish we had refinement
> types.

O.k.  I could raise an error in x86-translate if I ever try to translate
an MachineOutput.Operand.Void.

Does this extend to not having any pseudo-registers of type void?  

I noticed that the c-codegen removed the primop case of:

	     | MLton_eq => if Type.isVoid(Operand.ty(hd args))
			      then (printDst(); print C.truee; print ";\n")
			   else doit()

My corresponding code checked the sizes of the operands (which was the
closest thing I had to types, but it meant adding a size VOID which didn't
correspond to a real size).

In any event, even if there aren't supposed to be any pseudo-regs of type
void in the statements, on a self-compile, I get a pseudo-reg of type void
being listed in a live in list.