constant switch test bug in x86Translate

[Stephen Weeks]

> > Sounds good.  When you get a stable codegen again, send it out and I'll try to
> > recreate the "mlton: toX86Operand: strange Offset" bug.
> 
> Here's the update.  I also added in printing of the base and offsets in
> the places in toX86Operand which might raise the strange bug.  You should
> see
> mlton: toX86Operand: strange Offset index: ???
> with ??? appropriately filled in.

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.

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