Hoopl.Graph

ghc-8.6.3: The GHC API

Safe Haskell | None
Language | Haskell2010

Hoopl.Graph

Synopsis

- type Body n = LabelMap (Block n C C)
- type Graph = Graph' Block
- data Graph' block (n :: * -> * -> *) e x where
  - GNil :: Graph' block n O O
  - GUnit :: block n O O -> Graph' block n O O
  - GMany :: MaybeO e (block n O C) -> Body' block n -> MaybeO x (block n C O) -> Graph' block n e x
- class NonLocal thing where
  - entryLabel :: thing C x -> Label
  - successors :: thing e C -> [Label]
- addBlock :: (NonLocal block, HasDebugCallStack) => block C C -> LabelMap (block C C) -> LabelMap (block C C)
- bodyList :: Body' block n -> [(Label, block n C C)]
- emptyBody :: Body' block n
- labelsDefined :: forall block n e x. NonLocal (block n) => Graph' block n e x -> LabelSet
- mapGraph :: (forall e x. n e x -> n' e x) -> Graph n e x -> Graph n' e x
- mapGraphBlocks :: forall block n block' n' e x. (forall e x. block n e x -> block' n' e x) -> Graph' block n e x -> Graph' block' n' e x
- revPostorderFrom :: forall block. NonLocal block => LabelMap (block C C) -> Label -> [block C C]

# Documentation

type Body n = LabelMap (Block n C C) #

A (possibly empty) collection of closed/closed blocks

type Graph = Graph' Block #

A control-flow graph, which may take any of four shapes (O/O, OC, CO, C/C). A graph open at the entry has a single, distinguished, anonymous entry point; if a graph is closed at the entry, its entry point(s) are supplied by a context.

data Graph' block (n :: * -> * -> *) e x where #

`Graph'` is abstracted over the block type, so that we can build graphs of annotated blocks for example (Compiler.Hoopl.Dataflow needs this).

Constructors

GNil :: Graph' block n O O |
GUnit :: block n O O -> Graph' block n O O |
GMany :: MaybeO e (block n O C) -> Body' block n -> MaybeO x (block n C O) -> Graph' block n e x |

Instances

Outputable (Graph CmmNode e x) # |
Instance details Defined in PprCmm Methods ppr :: Graph CmmNode e x -> SDoc # pprPrec :: Rational -> Graph CmmNode e x -> SDoc #

class NonLocal thing where #

Gives access to the anchor points for nonlocal edges as well as the edges themselves

Methods

entryLabel #

Arguments

:: thing C x |
-> Label | The label of a first node or block

successors #

Arguments

:: thing e C |
-> [Label] | Gives control-flow successors

Instances

NonLocal CmmNode # |
Instance details Defined in CmmNode Methods entryLabel :: CmmNode C x -> Label # successors :: CmmNode e C -> [Label] #
NonLocal n => NonLocal (Block n) # |
Instance details Defined in Hoopl.Graph Methods entryLabel :: Block n C x -> Label # successors :: Block n e C -> [Label] #

addBlock :: (NonLocal block, HasDebugCallStack) => block C C -> LabelMap (block C C) -> LabelMap (block C C) #

bodyList :: Body' block n -> [(Label, block n C C)] #

emptyBody :: Body' block n #

labelsDefined :: forall block n e x. NonLocal (block n) => Graph' block n e x -> LabelSet #

mapGraph :: (forall e x. n e x -> n' e x) -> Graph n e x -> Graph n' e x #

Maps over all nodes in a graph.

mapGraphBlocks :: forall block n block' n' e x. (forall e x. block n e x -> block' n' e x) -> Graph' block n e x -> Graph' block' n' e x #

Function `mapGraphBlocks` enables a change of representation of blocks, nodes, or both. It lifts a polymorphic block transform into a polymorphic graph transform. When the block representation stabilizes, a similar function should be provided for blocks.

revPostorderFrom :: forall block. NonLocal block => LabelMap (block C C) -> Label -> [block C C] #

Returns a list of blocks reachable from the provided Labels in the reverse postorder.

This is the most important traversal over this data structure. It drops unreachable code and puts blocks in an order that is good for solving forward dataflow problems quickly. The reverse order is good for solving backward dataflow problems quickly. The forward order is also reasonably good for emitting instructions, except that it will not usually exploit Forrest Baskett's trick of eliminating the unconditional branch from a loop. For that you would need a more serious analysis, probably based on dominators, to identify loop headers.

For forward analyses we want reverse postorder visitation, consider: `A -> [B,C] B -> D C -> D` Postorder: [D, C, B, A] (or [D, B, C, A]) Reverse postorder: [A, B, C, D] (or [A, C, B, D]) This matters for, e.g., forward analysis, because we want to analyze *both* B and C before we analyze D.