[MLton] PackWord to/from nonsense

[Matthew Fluet]

On Wed, 8 Jul 2009, Wesley W. Terpstra wrote:
> On Wed, Jul 8, 2009 at 5:26 PM, Matthew Fluet <fluet at tti-c.org> wrote:
>> A number of 64-bit operations can (and should) be implemented by the native
>> x86 codegen, to avoid the C calls.  This should help even in the presence of
>> conversion optimizations.
>
>
> True. However, my combineConversions pass eliminates nearly all the cases
> that matter. ;) Improving the x86 codegen also won't be able to eliminate
> the Overflow tests in Int conversions the way my pass does.

No, but for the cases where the Overflow test couldn't be eliminated, it 
would still be nice to avoid bouncing through C calls.

> I'm not sure why you call them "unsafe" versions.  Your proposed PACK_WORD
>> signature (with the "type word" specification) wouldn't be unsafe in any
>> way.
>
> I meant PackWord versions without bounds checking. I would still really like
> exposed this somewhere. The Unsafe library, for example.

O.k.  Alternatively, someone could write a bounds check elimination pass. 
;-)

> In general, yes, conversion optimization should be a win. However, the
>> "clean-up" optimizations aren't commonArg and knownCase.  The SSA shrinker
>> (ssa/shrink.fun) will perform the necessary simplifications:
>>  * copy propagation of x_3 = x_1 (replace all uses of x_3 by x_1 and
>>    eliminate the x_3 variable)
>>  * prim-app folding of Word64_eq (x_2, x_2) to true
>>  * case simplification of a manifest discriminant
>
> Ok, well those passes definitely do the job from the experiments I've done.

I think what you are seeing is the use of the SSA shrinker at the end of 
every optimization pass.  Basically, you would see the clean up after the 
next pass, regardless of what that pass was.

>> knownCase handles case simplification when the discriminant is only
>> manifest on some of the incoming edges.
>
> Alright. Is my optimization pass in the wrong spot then? I put it right
> before commonSubexp.

See comments in other message.