constant switch test bug in x86Translate

[Matthew Fluet]

> I have recreated the bug.  The problem is that the CPS contains a global
> declaration 
> 	val global_6408 = NONE_273()
> and a case statement
> 	case global_6408 of
>             NONE_273 => L_29497
>           | SOME_283 => L_29496
> The backend generates code for the case like
> 	SwitchIP (IntAsPointer (1), L_29497, L_70431)
> where the pointer clause does an offset of a constant.
> 	L_70431:
> 		OP(IntAsPointer (1),0)
> 
> This is valid code, because L_70431 is dead.  This code will never occur if
> the CPS program has been shrunk to fixed-point, but I can't guarantee that it
> will never occur since that isn't done.  So the right thing to do is either for
> the backend or the code generator to generate a call to MLton_bug.  My gut
> feeling is it belongs in the backend.

Well, it's easy enough to set up the backend to produce an operand for
that case, but it would segfault if the operand were ever used during
execution.  But, that should let you produce an executable, if you are
still hunting other bugs.

On the other hand, it would be fairly difficult to generate a call to
MLton_bug -- the translation of each operand would have to return either
an operand or the code to call MLton_bug; that would mean lots of cases on
the result of the translation. 

> > SML/NJ runs out of memory (in one
> > of the cps simplify phases) when I try compiling a G1 mlton, so I haven't
> > been able to recreate the bug.
> 
> Is this a new and repeatable problem?  I haven't observed it running on a 512M
> machine.

It's only been with that snapshot you put up yesterday.  I assumed that it
had to do with the eliminated cps simplifications that just left a bigger
program for some later phases.  This machine also has somewhat less
memory:

[fluet@lennon fluet]$ cat /proc/meminfo 
        total:    used:    free:  shared: buffers:  cached:
Mem:  200900608 159145984 41754624        0 11472896 51773440
Swap: 255459328  5144576 250314752