CVS commit

[Matthew Fluet]

> > # directive: Cache: caches: MEM<l>{Temp}[(indexTemp)+(0*4)] -> %eax 
> > entries:
> > %esi MEM<l>{GCStateHold}[((gcState+12))+(0*4)] 1978 false NO
> > %edi MEM<l>{GCStateHold}[((gcState+40))+(0*4)] 924 false NO
> > %ebp MEM<l>{Locals}[(localpointer)+(4*4)] 979 false NO
> > %eax MEM<l>{Temp}[(indexTemp)+(0*4)] 1019 true NO
> > %edx MEM<l>{Locals}[(localpointer)+(5*4)] 1019 false NO
> > %esp MEM<l>{Temp}[(indexTemp)+(0*4)] 1039 false NO
> > reserved:
> > %eax
> > fltstack:
> 
> Yuck!  The "really bad thing" about this is the register allocation thinks
> that indexTemp is in both %eax and $esp.  

Got it.  I updated
http://www.cs.cornell.edu/People/fluet/MLton/x86-allocate-registers.tgz

Here's the CVS log:

The new implementation of cache mistakenly reserved _all_ cached values,
not just the ones with the reserve flag set.  Normally, this isn't a
problem -- caches are using for setting up %esp for a C call (where it is
reserved) and for setting up intra-procedural live registers (where they
are also reserved).  It's also used for forcing the index into a jump
table into %eax (where it is not reserved).  When the index isn't used in
the target of the jump, it should be trashed, but the reserved flag kept
it around.  Even this didn't pimp us until we absolutely needed %eax for
something else -- for an idiv instruction in tststrcmp.sml and for the
index of a subsequent jump-table in mlton.cm.  (This also explains why the
"really bad thing" of having the register allocator believe that indexTemp
was in two places at once -- really they were the indexTemps for two
different jump tables, which can share the same spill location because
we're never using two jump tables simultaneously.)