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).