Optimizer too smart....

[Daniel Wang]

"Stephen Weeks" <sweeks@intertrust.com> writes:

> > So, I'm running into a psudo-bug. In that the optimizer (Cps.simplify) is
> > doing too much work. In particular I pass datatypes to primitve C functions
> 
> This is a bad idea.  I strongly recommend that you write coercion
> functions in the ML code to convert to/from types whose representation
> is guaranteed.  The FFI section of the manual describes the allowed
> types.

What I need is the "pointer address" of the object so I can hash it and have
my GC preserver sharing. Which is kind of special. 

> > and it's optimizing the representation in such a way incompatible with the
> > old representation causing things to not type-check (i.e. I'm getting a type
> > error not a segfault...)
> 
> I'm confused where you're getting the type error -- in the Cps
> typechecker, in the C typechecker, or somewhere else?
 
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. 

basicaly for each datatype of type T. I introduce a new primtive 

val insertTbl: (T * T) -> unit
val findTbl : T -> T option

the T option type is represented as a "word in the CPS" in MLTON. 

> Many of the optimization passes on the Cps change datatype
> declarations (useless, simplify-types, redundant,
> remove-unused-constructors, ...).  Also, the backend does a bit more
> representation optimization (representation.sig), which can't be
> turned off.

The backend optimizations aren't a problem. 

> Basically, I don't see any easy way to guarantee datatype
> representations.

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

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