[MLton] MLton misses 'assumed' Word optimization

[Matthew Fluet]

> >From <http://www.standardml.org/Basis/word.html>
> 
> 	It also is assumed that implementations will catch the idiom of
> 	converting between words and integers of differing precisions using
> 	an intermediate representation (e.g., Word32.fromLargeWord o
> 	Word8.toLargeWord) and optimize these conversions.

Assumed, but not required. ;-)

> I'm surpised by two things here:
> 	1. MLton didn't use WordU16_toWord32

Indeed that is a reasonable optimization.  There are a slew of (minor) 
optimizations that are not applied, because the fast primitive simplifier 
only looks at a single primitive and it's operands.  Most of the algebraic 
identities applied require one or more operands to be a constant.

A good project might be to write an SSA optimization pass that applies 
simplifications based on "nested" applications of primitives.  For anyone 
interested, I suggest also looking at:

Effective Partial Redundancy Elimination
Preston Briggs, Keith D. Cooper
PLDI '94

> 	2. That WordU16_toWord32 requires a C function call at all

I think you mean WordU16_toWord64?  The x86-codegen does not handle 64-bit
operations ideally.  You can see from codegen/x86-codegen/x86-mlton.fun 
that comparisons, mul, quot, rem, rotates, shifts, and coercions are all 
implemented by C calls.  

> Am I off my rocker here; should MLton really be doing this?

It is the behavior I would expect from MLton, given MLton's current 
implementation.  As to whether or not this is the desirable behavior is 
another question.

> It seems that this works for Int..?

That does appear to be the case.  I don't know if the coercions are 
specifically optimized in this case, or if it is a consequence of the 
internal representation of IntInf.int.