[MLton-user] option ref optimized to a null pointer?
Jesper Louis Andersen
jesper.louis.andersen at gmail.com
Sat Nov 24 14:05:05 PST 2007
While here, also take a look at some of the SSA2 optimization phases. Especially
the DeepFlatten and RefFlatten optimization runs:
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:
> 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
More information about the MLton-user