+{-
+
+This module implements two useful tools:
+
+ 1. An iterative solver for dataflow problems
+
+ 2. The combined dataflow-analysis-and-transformation framework
+ described by Lerner, Grove, and Chambers in their excellent
+ 2002 POPL paper (http://tinyurl.com/3zycbr or
+ http://tinyurl.com/3pnscd).
+
+Each tool comes in two flavors: one for forward dataflow problems
+and one for backward dataflow problems.
+
+We quote the paper above:
+
+ Dataflow analyses can have mutually beneficial interactions.
+ Previous efforts to exploit these interactions have either
+ (1) iteratively performed each individual analysis until no
+ further improvements are discovered or (2) developed "super-
+ analyses" that manually combine conceptually separate anal-
+ yses. We have devised a new approach that allows anal-
+ yses to be defined independently while still enabling them
+ to be combined automatically and profitably. Our approach
+ avoids the loss of precision associated with iterating indi-
+ vidual analyses and the implementation difficulties of man-
+ ually writing a super-analysis.
+
+The key idea is to provide at each CFG node not only a dataflow
+transfer function but also a rewriting function that has the option to
+replace the node with a new (possibly empty) graph. The rewriting
+function takes a dataflow fact as input, and the fact is used to
+justify any rewriting. For example, in a backward problem, the fact
+that variable x is dead can be used to justify rewriting node
+ x := e
+to the empty graph. In a forward problem, the fact that x == 7 can
+be used to justify rewriting node
+ y := x + 1
+to
+ y := 8
+which in turn will be analyzed and produce a new fact:
+x == 7 and y == 8.
+
+In its most general form, this module takes as input graph, transfer
+equations, rewrites, and an initial set of dataflow facts, and
+iteratively computes a new graph and a new set of dataflow facts such
+that
+ * The set of facts is a fixed point of the transfer equations
+ * The graph has been rewritten as much as is consistent with
+ the given facts and requested rewriting depth (see below)
+N.B. 'A set of facts' is shorthand for 'A finite map from CFG label to fact'.
+
+The types of transfer equations, rewrites, and fixed points are
+different for forward and backward problems. To avoid cluttering the
+name space with two versions of every names, other names such as
+zdfSolveFrom are overloaded to work in both forward or backward
+directions. This design decision is based on experience with the
+predecessor module, now called ZipDataflow0 and destined for the bit bucket.
+
+
+This module is deliberately very abstract. It is a completely general
+framework and well-nigh impossible to understand in isolation. The
+cautious reader will begin with some concrete examples in the form of
+clients. NR recommends
+
+ CmmLiveZ A simple liveness analysis
+
+ CmmSpillReload.removeDeadAssignmentsAndReloads
+ A piece of spaghetti to pull on, which leads to
+ - a two-part liveness analysis that tracks
+ variables live in registers and live on the stack
+ - elimination of assignments to dead variables
+ - elimination of redundant reloads
+
+Even hearty souls should avoid the CmmProcPointZ client, at least for
+the time being.
+
+-}
+
+
+{- ============ TRANSFER FUNCTIONS AND REWRITES =========== -}
+
+-- | For a backward transfer, you're given the fact on a node's
+-- outedge and you compute the fact on the inedge. Facts have type 'a'.
+-- A last node may have multiple outedges, each pointing to a labelled
+-- block, so instead of a fact it is given a mapping from BlockId to fact.