Optimizer too smart....

Stephen Weeks MLton@research.nj.nec.com
Wed, 2 Feb 2000 20:50:09 -0800 (PST)


> In the CPS phase it type checks initially but at some point there is some
> phase that I assume changes the representation in such a way that the
> primtive  no longer type checks. I'm not exactly sure how it does it
> though.. let me see if I can isolate the "bug" and be more specific. 

The only way I can think of offhand that this might happen is if you
introduce a polymorphic primitive.  I'm not sure if your insertTbl
stuff is using a family of monomorphic, dynamically generated
primitives, or is using a single polymorphic primitive.  For any
polymorphic primitive, you must change atoms/extract-targs.fun to do
the right thing (which is hopefully obvious if you look at the
source).  If this isn't the problem, there may be a compiler bug, and
you should try to isolate the offending pass.

> The only real guarantee I need is that certain value carrying constructors
> which should be boxed stay boxed.
> 
> Actually, I can get by with just a "getId"  primitve that returns a unique
> id for each object. (I can disable the MLton GC so pointer address is fine,
> and can handle the non value carrying constructors in a special way...)

This should be easy to do.  You need a single polymorphic primitive,
which should be treated by the compiler very much like the current
"Size" primitive.  I.E., you add a new Name.t to atoms/prim.{fun,sig}
and modify atoms/extract-targs.fun and backend/machine.fun.  This
primitive will return 1 for objects which aren't pointers, and return
the address of the object (i.e. value of the pointer) for all heap
allocated objects.

> The only down side of this approach, was that I lose some gurantess that, I
> was able to propagate all the way through MLton.

I don't understand this drawback (I assume as compared to the
insertTbl/findTbl approach).