a more efficient loopForestSteensgaard

[Matthew Fluet]

> I'd like to consider replacing the return type of
> loopForestSteensgaard with the above, but I don't understand the
> relationship well enough with what's currently there or with how it's
> used in x86LoopInfo.  Matthew, could you take a look at the code, make
> sure you agree it is computing the same loop forest (and is more
> efficient), and give me your thoughts on converting to the above as
> the representation of the loop forest?  Thanks.

Here are the ways I've been using loopForest information in x86LoopInfo
x86LiveTransfer, and x86GenerateTransfers:
 - nodes that are marked as a loopHeader get extra alignment, 
    even if they are a fall through label; so I don't think that marking
    every node in a trivial scc as a header is a good idea.
 - given a node, x86LiveTransfer wants to be able to compute all of the
    nodes in same loop (actually, all of the nodes in the the deepest
    nested loop of which the original node is a member)
 - x86GenerateTransfers wants to be able to compute the following to
    decide how to layout blocks at an Iff:
 if neither of the truee's and falsee's blocks have been generated,
  then fall thru to the label with the least "loop-distance" from the
  Iff's label (where loop distance from l1 to l2 is NONE if l1 and l2 are
  in non-nested loops, and SOME (d(l2) - d(l1)) where d(l) is the depth of
  the deepest occurence of l in the loop forest); this favors staying in
  the same loop or entering nested loops over exiting loops

So, at a minimum, I would want an isHeader predicate returned by a loop
forest calculation.  The other stuff I could probably compute from the
proposed return type.  

I guess I would suggest:

      datatype t = T of {loops: {headers: Node.t vector,
                                 inLoop: Node.t vector,
				 child: t} vector,
			 notInLoop: Node.t vector}

Yes, inLoop could be computed from the original datatype by concating all
of the notInLoop vectors down the child, but (1) the codegen more often
wants to know what's in a loop, not what's not in a loop, and (2) it's
already calculated as the scc, so we just need to save it in the datatype.

Did you have something specific in mind for notInLoop?