x86 update

[Matthew Fluet]

P.S. (pre-script)  Maybe none of this applies after looking at Steve's
latest message, but it's probably useful information to pass around.

> I'll start a compile with this change and the new codegen.

Right now I'm going to put my money on the explosion occuring in a
computeLiveTransfer phase (or maybe verifyLiveInfo).  If it's the former,
try compiling with -native-live-transfer false.

I'm thinking about these two phases because they are the only places where
some loops might diverge (although they shouldn't on a correct program).
I'm guessing computeLiveTransfer because I could see the recursion there
building up stack.  The recursion in verifyLiveInfo is tail-recursive, so
hopefully no space leak there.

The computeLiveTransfer phase uses a quick heuristic to choose which
pseudo-regs to carry in registers between blocks; currently, it's
computing the average "distance" between the last use/def of a pseudo-reg
and the next use of the pseudo-reg.  This could diverge if traversing
the control-flow graph backwards we never find a def or if traversing the
graph forward we never find a use; but, if the liveness information is
correct at each block label, then it shouldn't happen (i.e., if X is live,
it should have been defined along every possible incoming path and it
should be used down some outgoing path).

The problem with verifyLiveInfo is a little more subtle.  Recall that I'm
"completing" the live variable info for each block -- most importantly,
filling in for the new blocks introduced by overflow checking.  Secondly,
I'm fixing any incorrectly reported liveness information.  I'm using the
standard fixed-point computation for the liveness, a la dragon book. 

Here's the subtlety -- the algorithm will certainly converge if I start
with the assumption that no variables are live at any block label (i.e.,
bot).  But that's too expensive, and, in theory, the previous phase of
liveness analysis already filled in a lot of that information in.
However, if that information is wrong, and not a chain from bot to
the fixed-point, it might diverge.  I actually saw this happen once before
when I was working on verifyLiveInfo -- I traced the problem back to a
spurious assertion that a pseudo-register of type void was live but there
were no uses or defs of it anywhere.  This got propagated back into this
complex control flow loop where it was just passed around and around
(reminded me a little of the generators in Conway's game of life).  What
really bothered me was the fact that it diverged or didn't depending on
which version of verifyLiveInfo I was using; the difference was between
using a working list for efficiency and only recomputing liveness for the
essential blocks or recomputing it for everything.  The later would stomp
out the void pseudo-reg before it got propagated around, but the former
wouldn't.  

Since I only ever saw this once with a void pseudo-reg and voids are never
produced by backend anymore, I had hoped it would go away.