x86 update

[Matthew Fluet]

I tracked down the floating-point bug I mentioned yesterday.  Essentially,
it arose from the fact that I wasn't recognizing that 
SD(176) (a double, hence 8 bytes) and SP(180)
were members of the mayAlias relation.  The issue arose when
copy-propagation pushed an (unloaded) use of SP(180) past a def (and
commit) of SD(176).  Obviously, that corrupted the pointer, and a
predictable seg-fault occured.  I've fixed up the mayAlias function to
correctly handle the overlap due to different sized datatypes.

The other question I wanted to ask was whether or not there have been any
important changes to the GC since 20001004?  I was going to add Suresh's
suggestion to put some frameLayout information into the code-stream.  This
would require changes to gc.c, gc.h, c-codegen.fun and x86-codegen.fun.

My current idea is to simply put an integer before each label which
corresponds to the index into the frameLayouts array.  That will incur one
extra level of indirection than the C-backend, but it should be better
than the hashtable lookup that's currently being used.  I could avoid that
level of indirection by putting the framesize and a pointer to the
frameOffsets array before the label, but that would mean either
duplicating data in the frameLayouts array or modifying the invariant
function in gc.c to not walk through the frameLayouts array.  I'm strongly
leaning towards the first option, because it means minor changes to
gc.{c,h} (basically, removing the hashing and adding in the indirection
lookup).  Also, in order to put the addresses of the frameOffsets in the
assembly files, we would need to extern all of the frameOffsets; not
really a problem, but it would add more to the namespace. 

BTW, I found a minor bug in the calculation of maxFrameSize in
backend.fun; this was tripping the 
assert(layout->numBytes <= s->maxFrameSize);
in the invariant function of gc.c when debugging was turned on (yet
another reason to go with the first option).  I discovered it when
compiling regression/kitsimple.sml.  I think that the bug is in the
genCont function of backend.fun.  The frame size for that limitCheck is
not compared to the maxFrameSize set by allocate-registers.  Similarly at
the end under the (* Build initGlobals chunk *) comment, another limit
check with a new frame size (although I suspect that no program has it's
maxFrameSize dominated by the 1 word frame size of initGlobals).