Optimizer too smart....

[Daniel Wang]

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

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

They're a dynamically generated family of monomorphic pritives. i.e. the
targs argument to the primApp is always the empty list.

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

Ahh.. okay, I'll do some more digging...

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

I think, I'll go ahead and hack this in regardless of what's going on with
the current system, since it'll leave me with a cleaner solution in the
end... 

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

If I'm using this getId primtive at the mlton CPS level, it means MLton can
break certain things in a way that still typechecks that will lead to a
segfault..

Right now I have something like

val polyInsertTbl : ('a * 'a) -> unit

as just a C primitive which I have to get right...

with getId I'd have to implement it with getId and a more primitive notion.


val getId         : 'a -> word
val insertTbl     : (word * word) -> unit
fun polyInsertTbl (x:'a,y:'a) = insertTbl(getId x,getId y)

Before polyInsertTbl was atomic and I didn't worry about mlton doing the
"wrong" thing... but with the getId approach if mlton goofs it might rewrite
polyInsterTbl in a wrong way like..

fun polyInsertTbl (x:'a,y:'a) = insertTbl(0w0,getId y)

and I'd get a nasty segfault.... keeping the primitve "primitve" just gives
me a stronger guarantee of safety... if I know the mlton code type checks, I
just know certain things aren't going to go wrong..... but I'm already
loosing some safety guarantees in other ways so it's not a real problem.