[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