constant switch test bug in x86Translate

[Stephen Weeks]

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

I meant *backend*, not *codegen*.  I.E. you can leave the codegen as is (was?).
I want the codegen to raise an error at compile time if it sees a deref into
memory.

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

Makes sense.  I'm not gonna worry about it.