-native self compile problems

[Matthew Fluet]

> I just tried a new G0 -> G1 native compile and it failed with an assertion
> failure (toX86Blocks: Move) in the native backend.  I've made a lot of changes
> to other parts of the compiler, but the only changes I've made to the native
> backend were in x86-translate to add Word{8,32}_neg and the new outputAssembly.
> A snapshot of the sources that produces the failure is available at
> http://www.star-lab.com/sweeks/mlton.tgz.  Here is the log.

>    x86 code gen starting
>       outputC starting
>       outputC finished in 1.170
>       outputAssembly starting
> 	 translateChunk raised
>       outputAssembly raised in 5.670
>    x86 code gen raised in 130.760
> compile raised in 2049.230
> mlton: assertion failure: toX86Blocks: Move

I think that corresponds to a type-error in the corresponding
MachineOutput.Statement.Move {src, dst}
expression.

All that assertion does is compare the x86 sizes of src and dst for
equality.  The x86 size of a MachineOutput.Operand.t is calculated by a
simple map on it's type.  The map (from x86-mlton.fun) looks like:

  local
    open MachineOutput.Type
  in
    fun toX86Size t
      = case dest t
	  of Char => x86.Size.BYTE
	   | Double => x86.Size.DBLE
	   | Int => x86.Size.LONG
	   | Pointer => x86.Size.LONG
	   | Uint => x86.Size.LONG
	   | Void => x86.Size.VOID
  end

My understanding was that a MachineOutput.Statement.Move would always have
source and destination of the same type.

If the C backend produces an executable, then my guess is that somewhere
along the line a coercion function got dropped, which C is adding back.
Otherwise, I'd guess that void creeped in somehow.