[MLton-user] option ref optimized to a null pointer?

[Jesper Louis Andersen]

While here, also take a look at some of the SSA2 optimization phases. Especially
the DeepFlatten and RefFlatten optimization runs:

http://mlton.org/RefFlatten
http://mlton.org/DeepFlatten

Which looks like they kick in here and does wonders.

On Nov 24, 2007 10:07 PM, Vesa Karvonen <vesa.a.j.k at gmail.com> wrote:
> On Nov 24, 2007 5:15 PM, Wesley W. Terpstra
> <terpstra at dvs1.informatik.tu-darmstadt.de> wrote:
> > It seems MLton represented the type '(int * int ref) option array' as
> > I would have done it in C. [...]
> >
> > What surprised me is that it seems MLton can turn the NONE case of
> > option + pointer into a "null pointer". [...]
>
> That is what I would expect.  IOW, I believe that it is a very basic
> optimization.  Not all bit patterns correspond to valid pointers, so a
> compiler is free to use invalid patterns to represent other values.
> In particular, when pointers are guaranteed to be aligned by some
> power of two (2^2 or 2^3 in MLton), there are some bits in pointer
> values that can be used to store tag values (and the rest of the bits
> can be used to store other information).
>
> > What rules must I obey to make sure MLton can continue to apply these
> > optimizations? For the flattened tuple, I gather I shouldn't try
> > ripping the 'int ref' out of the tuple and passing it through a
> > function barrier. But  when does this 'option ref' -> 'null pointer'
> > optimization happen? Always?
>
> Note that your type was actually "(int * int ref) option array".
>
> Some time ago, while grepping through MLton's commit logs for
> information on some thing, I noticed the following log message, that
> relates to your question:
>
>   http://mlton.org/cgi-bin/viewsvn.cgi?rev=3005&view=rev
>
> It would seem to me that MLton has an expressive framework for
> representation optimizations. So, I think that it would probably be
> more productive to approach the problem from the other direction.  If
> you run into cases where MLton is unable to optimize the
> representation as you'd expect, you should report it and maybe MLton
> can be improved to handle the case better.  I think that learning to
> write code in such a way that some compiler will be able to generate
> good code from it is ultimately not very productive (google for the
> story about Levine the Genius Tailor).
>
> -Vesa Karvonen
>
>
> _______________________________________________
> MLton-user mailing list
> MLton-user at mlton.org
> http://mlton.org/mailman/listinfo/mlton-user
>
>