[MLton] PackWord to/from nonsense

Wesley W. Terpstra wesley at terpstra.ca
Wed Jul 8 08:36:47 PDT 2009


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.


> You can use the same technique that the Basis Library uses.  There is an
> (undocumented) MLB path variable SEQINDEX_INT which expands to either
> "int32" or "int64", depending on the size of indices of the target platform.


Sneaky. At this point, though, (assuming my optimization pass is ok to
commit) the only benefit I get from using _prim is the lack of bounds
checking.

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.

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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20090708/b966cca1/attachment.htm


More information about the MLton mailing list