[MLton] MLton misses 'assumed' Word optimization

[Stephen Weeks]

> So the  WordS16_toWord32  that you see is the  toInt.  There is a lot of
> code off the fast-path that handles the case when the IntInf.fromInt
> can't fit the 32-bit integer into the high 31-bits used to represent a 
> "small" IntInf.int.  Of course, when coming from a 16-bit integer, this 
> path is never taken, but neither is it optimized away.

Yeah.  This is another nice optimizer project -- keep track of bits in
words that are known, kind of a bitwise constant propagation.  That
would be able to realize that the slow path is unreachable in this
case.

BTW, Wesley, given the current MLton implementation, you could use the
following more efficient definition of convertWord.

  val convertWord = Word32.fromInt o Word16.toInt

That will be optimized into a single primapp of WordU16_toWord32,
which the x86 codegen will implement using an instruction, not a C
call.