SSA simplify passes

[Matthew Fluet]

> Anyways, I'm hopeful that after looking at the flattener, we should be
> able to get to a point where the tuple reconstruction
> elimination can be permanently left on in the shrinker.

I think I see the main problem in the flattener.  

Consider the following, as input to the flatten pass:

list_3 = nil_0 | ::_3 of ((real * list_3))
fun main_0 () = L_0 ()
...
  L_231 (env_1: (list_3 * real))
    x_680: list_3 = #1 env_1
    x_681: real = #2 env_1
    x_679: (real * list_3) = (x_681, x_680)
    L_230 (f2_0 (x_682, x_679)) None
...
fun f2_0 (env_6: real, x_1338: (real * list_3)): Some ((real)) (None) = L_801 ()
  L_801 ()
    x_1348: list_3 = #2 x_1338
    x_1343: real = #1 x_1338
    case x_1348 of
      ::_3 => L_805 | nil_0 => L_806
  L_806 ()
    max_0 (x_1343, env_6)
  L_805 (x_1344: (real * list_3))
    x_1346: list_3 = #2 x_1344
    x_1347: real = #1 x_1344
    x_1345: (real * list_3) = (x_1347, x_1346)
    L_804 (f2_0 (env_6, x_1345)) None
...

The only meaningful difference when compiled with -tuple-recon-elim 2 is
that in L_805 the tuple isn't deconstructed and reconstructed.

In the above code, we can flatten the second argument to f2_0, because it
is explicitly available as a tuple at each invocation.  Independently, we
can flatten the argument to the ::_3 constructor.

On the other hand, when compiled with -tuple-recon-elim 2, the second
argument to f2_0 is _not_ explicitly available as a tuple at the recursive
call, so we fail to flatten it.  Unfortunately, independently, we do
flatten the argument to the ::_3 constructor.

I think we really need to tie the two together (I don't see why a
dependency couldn't occur in the other direction), so that we flatten the
second argument to f2_0 conditionally on being able to flatten the
argument to the ::_3 constructor.  I'll see about integrating something
like this tomorrow.


> > nucleic: Looking at the datatypes of the -loop-passes 2 version, my guess
> > is too much flattening of tuples.  In particular, something like this 
> > looks bad:
> ...
>  
> Yuck.  Maybe arg flattening should only happen if a large fraction of
> the selects are inevitable.

Any further thoughts on this?