Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] View of /sml/trunk/src/MLRISC/Doc/mlrisc-ir.html
ViewVC logotype

View of /sml/trunk/src/MLRISC/Doc/mlrisc-ir.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 410 - (download) (as text) (annotate)
Fri Sep 3 00:25:03 1999 UTC (20 years, 8 months ago)
Original Path: sml/branches/SMLNJ/src/MLRISC/Doc/mlrisc-ir.html
File size: 26105 byte(s)
This commit was manufactured by cvs2svn to create branch 'SMLNJ'.
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.07 [en] (X11; I; Linux 2.2.7 i686) [Netscape]">
<BODY bgcolor="#FFFFFF">

<h2> Introduction </h2>

In this section we will describe the MLRISC intermediate representation.

<h3>Control Flow Graph</h3>

The control flow graph is the main view of the IR.  
A control flow graph satisfies the following signature:
 signature <a href="../IR/mlrisc-cfg.sig" target=code>CONTROL_FLOW_GRAPH</a> = sig
   structure I : INSTRUCTIONS
   structure B : BLOCK_NAMES
   structure P : PSEUDO_OPS
   structure C : CELLS
   structure W : FIXED_POINT 
      sharing I.C = C

   {\it definition of type} weight
   {\it definition of type} block_kind
   {\it definition of type} data
   {\it definition of type} block
   {\it definition of type} edge_kind
   {\it definition of type} edge_info
   {\it definition of type} cfg
   {\it operations on a cfg} 

The following structures nested within a CFG:
   <li> <tt>I : INSTRUCTIONS</tt> is the instruction structure.
   <li> <tt>B : BLOCK_NAMES</tt> is the block name structure
   <li> <tt>P : PSEUDO_OPS</tt> is the structure with the definition
of pseudo ops.
   <li> <tt>C : CELLS</tt> is the cells structure describing the
register conventions of the architecture.
   <li> <tt>W : FIXED_POINT</tt> is a structure that contains
a fixed point type used in execution frequency annotations.

The type <tt>weight</tt> below is used in execution frequency annotations:
   type weight = W.fixed_point

There are a few different kinds of basic blocks, described
by the type <tt>block_kind</tt> below:
   datatype block_kind = 
       START          <em></em>
     | STOP           <em></em>
     | FUNCTION_ENTRY <em></em>
     | NORMAL         <em></em>
     | HYPERBLOCK     <em></em>

A basic block is defined as the datatype <tt>block</tt>, defined below:
   and data = LABEL  of Label.label
            | PSEUDO of P.pseudo_op

   and block = 
      BLOCK of
      {  id          : int,                       <em></em>
         kind        : block_kind,                 {\it(* block kind *)}
         name        : B.name,                     {\it(* block name *)}
         freq        : weight ref,                 {\it(* execution frequency *) }
         data        : data list ref,              {\it(* data preceding block *) }
         labels      : Label.label list ref,       {\it(* labels on blocks *) }
         insns       : I.instruction list ref,     {\it(* in rev order *)}
         annotations : Annotations.annotations ref {\it(* annotations *)}

Edges in a CFG are annotated with the type <tt>edge_info</tt>,
defined below:
   and edge_kind = ENTRY           <em></em>
                 | EXIT            <em></em>
                 | JUMP            <em></em>
                 | FALLSTHRU       <em></em>
                 | BRANCH of bool  <em></em>
                 | SWITCH of int   <em></em>
                 | SIDEEXIT of int <em></em>

   and edge_info = 
       EDGE of { k : edge_kind,                  {\it(* edge kind *)}
                 w : weight ref,                 {\it(* edge freq *)}
                 a : Annotations.annotations ref {\it(* annotations *)}

Type <tt>cfg</tt> below defines a control flow graph:
   type edge = edge_info edge
   type node = block node

   datatype info = 
       INFO of { regmap      : C.regmap,
                 annotations : Annotations.annotations ref,
                 firstBlock  : int ref,
                 reorder     : bool ref
   type cfg = (block,edge_info,info) graph

\paragraph{Low-level Interface}
   The following subsection describes the low-level interface to a CFG.
These functions should be used with care since they do not
always maintain high-level structural invariants imposed on
the representation.  In general, higher level interfaces exist
so knowledge of this interface is usually not necessary for customizing
   Various kinds of annotations on basic blocks are defined below:
   exception LIVEOUT of C.cellset    <em></em>
   exception CHANGED of unit -> unit
   exception CHANGEDONCE of unit -> unit
The annotation <tt>LIVEOUT</tt> is used record live-out information
on an escaping block.
The annotations <tt>CHANGED</tt> and <tt>CHANGEDONCE</tt> are used
internally for maintaining views on a CFG.  These should not be used

    The following are low-level functions for building new basic blocks.
The functions <tt>new</tt><em>XXX</em> build empty basic blocks of a specific
type.  The function <tt>defineLabel</tt> returns a label to a basic block;
and if one does not exist then a new label will be generated automatically.
The functions <tt>emit</tt> and <tt>show_block</tt> are low-level
routines for displaying a basic block.
   val newBlock          : int * B.name -> block      <em></em>
   val newStart          : int -> block               <em></em>
   val newStop           : int -> block               <em></em>
   val newFunctionEntry  : int -> block               <em></em>
   val copyBlock         : int * block -> block       <em></em>
   val defineLabel       : block -> Label.label       <em></em>
   val emit              : C.regmap -> block -> unit  <em></em>
   val show_block        : C.regmap -> block -> string 

   Methods for building a CFG are listed as follows:
   val cfg      : info -> cfg    
   val new      : C.regmap -> cfg
   val subgraph : cfg -> cfg     
   val init     : cfg -> unit    
   val changed  : cfg -> unit   
   val removeEdge : cfg -> edge -> unit
 Again, these methods should be used only with care.

  The following functions allow the user to extract low-level information
from a flowgraph.  Function <tt>regmap</tt> returns the current register map.
Function <tt>regmap</tt> returns a function that lookups the current register
map.  Function <tt>liveOut</tt> returns liveOut information from a block;
it returns the empty cellset if the block is not an escaping block.
Function <tt>fallsThruFrom</tt> takes a node id <em>v</em> and locates the
block <em>u</em> (if any) that flows into <em>v</em> without going through a branch
instruction.  Similarly, the function <tt>fallsThruTo</tt>  takes
a node id <em>u</em> and locates the block (if any) that <em>u</em> flows into
with going through a branch instruction.  If <em>u</em> falls through to
<em>v</em> in any feasible code layout <em>u</em> must preceed <em>v</em>.
   val regmap    : cfg -> C.regmap
   val reglookup : cfg -> C.register -> C.register
   val liveOut   : block -> C.cellset
   val fallsThruFrom : cfg * node_id -> node_id option
   val fallsThruTo   : cfg * node_id -> node_id option

   To support graph viewing of a CFG, the following low-level
primitives are provided: 
   val viewStyle      : cfg -> (block,edge_info,info) GraphLayout.style
   val viewLayout     : cfg -> GraphLayout.layout
   val headerText     : block -> string
   val footerText     : block -> string
   val subgraphLayout : { cfg : cfg, subgraph : cfg } -> GraphLayout.layout

   Finally, a miscellany function for control dependence graph building.
   val cdgEdge : edge_info -> bool <em></em>

The MLRISC intermediate representation is a composite
view of various compiler data structures, including the control
flow graph, (post-)dominator trees, control dependence graph, and
loop nesting tree.   Basic compiler optimizations in MLRISC
operate on this data structure; advance optimizations
operate on more complex representations which use this
representation as the base layer.  
   \caption{The MLRISC IR}

This IR provides a few additional functionalities:
  <li> {\bf Edge frequencies} -- execution frequencies
are maintained on all control flow edges.
  <li> {\bf Extensible annotations} -- semantics information can be 
       represented as annotations on the graph. 
  <li> {\bf Multiple facets} -- 
   Facets are high-level views that automatically keep themselves
up-to-date.  Computed facets are cached and out-of-date facets 
are recomputed by demand.
The IR defines a mechanism to attach multiple facets to the IR.

The signature of the IR is listed in Figure~\ref{fig:mlrisc-ir}.
 signature <a href="../IR/mlrisc-ir.sig" target=code>MLRISC_IR</a> = sig
   structure I    : INSTRUCTIONS
   structure CFG  : CONTROL_FLOW_GRAPH
   structure Dom  : DOMINATOR_TREE
   structure Loop : LOOP_STRUCTURE
   structure Util : CFG_UTIL
      sharing Util.CFG = CFG
      sharing CFG.I = I 
      sharing Loop.Dom = CDG.Dom = Dom
   type cfg  = CFG.cfg  
   type IR   = CFG.cfg  
   type dom  = (CFG.block,CFG.edge_info,CFG.info) Dom.dominator_tree
   type pdom = (CFG.block,CFG.edge_info,CFG.info) Dom.postdominator_tree
   type cdg  = (CFG.block,CFG.edge_info,CFG.info) CDG.cdg
   type loop = (CFG.block,CFG.edge_info,CFG.info) Loop.loop_structure
   val dom   : IR -> dom
   val pdom  : IR -> pdom
   val cdg   : IR -> cdg
   val loop  : IR -> loop

   val changed : IR -> unit  
   val memo : (IR -> 'facet) -> IR -> 'facet
   val addLayout : string -> (IR -> GraphLayout.layout) -> unit
   val view : string -> IR -> unit      
   val views : string list -> IR -> unit      
   val viewSubgraph : IR -> cfg -> unit 
\caption{\label{fig:mlrisc-ir}MLRISC IR}

The following facets are predefined: dominator, post-dominator tree,
control dependence graph and loop nesting structure.
The functions <tt>dom</tt>, <tt>pdom</tt>, <tt>cdg</tt>, <tt>loop</tt>
are <font color="#ff0000">facet extraction</font> methods that
compute up-to-date views of these facets.

The following protocol is used for facets:
<li> {\bf When the IR is changed}, 
the function <tt>changed</tt> should be called to 
signal that all facets attached to the IR should be updated.
<li> {\bf To add a new facet} of type <tt>F</tt> that is computed by demand,
the programmer has to provide a facet construction 
function <tt>f : IR -> F</tt>.  Call the function <tt>mem</tt>
to register the new facet.  For example, let <tt>val g = memo f</tt>. 
Then the function <tt>g</tt> can be used to as a new facet extraction
function for facet <tt>F</tt>.
<li> {\bf To register a graph viewing function}, call
the function <tt>addLayout</tt> and provide an appropriate 
graph layout function.  For example, we can say
<tt>addLayout "F" layoutF</tt> to register a graph layout function
for a facet called ``F''.

To view an IR, the functions <tt>view</tt>, <tt>views</tt> or
<tt>viewSubgraph</tt> can be used.  They have the following interpretation:
<li> <tt>view</tt> computes a layout for one facet of the IR and displays
it.  The predefined facets are called
``dom'', ``pdom'', ``cdg'', ``loop.''  The IR can be
viewed as the facet ``cfg.'' In addition, there is a layout
named ``doms'' which displays the dominator tree and the post-dominator
tree together, with the post-dominator inverted.
<li> <tt>views</tt> computes a set of facets and displays it together
in one single picture.
<li> <tt>viewSubgraph</tt> layouts a subgraph of the IR.
This creates a picture with the subgraph highlighted and embedded
in the whole IR.

<h3>Building a CFG</h3>

There are two basic methods of building a CFG:
<li> convert a sequence of machine instructions
into a CFG through the emitter interface, described below, and 
<li> convert it from a <font color="#ff0000">cluster</font>, which is
the basic linearized representation used in the \MLRISC{} system.
The first method requires you to perform instruction selection
from a compiler front-end, but allows you to bypass all other
\MLRISC{} phases if desired.  The second method allows you
to take advantage of various \MLRISC's instruction selection modules
currently available.  We describe these methods in this section.

\paragraph{Directly from Instructions}
 Signature <tt>CODE_EMITTER</tt> below describes an abstract emitter interface
for accepting a linear stream of instructions from a source 
and perform a sequence of actions based on this
stream\footnote{Unlike the signature {\tt EMITTER\_NEW} or 
{\tt FLOWGRAPH\_GEN}, it has the advantage that it is not 
tied into any form of specific flowgraph representation.}.  

 signature <a href="../extensions/code-emitter.sig" target=code>CODE_EMITTER</a> = sig 
   structure I : INSTRUCTIONS
   structure C : CELLS
   structure P : PSEUDO_OPS
   structure B : BLOCK_NAMES
      sharing I.C = C

   type emitter =
   {  defineLabel : Label.label -> unit,   
      entryLabel  : Label.label -> unit,   
      exitBlock   : C.cellset -> unit,    
      pseudoOp    : P.pseudo\_op -> unit,  
      emitInstr   : I.instruction -> unit, 
      blockName   : B.name -> unit,       
      comment     : string -> unit,        
      init        : int -> unit,           
      finish      : unit -> unit   

The code emitter interface has the following informal protocol. 
 init(<em>n</em>)   & Initializes the emitter and signals that
               the back-end should 
               allocate space for <em>n</em> bytes of machine code.
               The number is ignored for non-machine code back-ends. \\
 defineLabel(<em>l</em>) & Defines a new label <em>l</em> at the current position.\\
 entryLabel(<em>l</em>)  & Defines a new entry label <em>l</em> at the current position.  
 An entry label defines an entry point into the current flow graph.
 Note that multiple entry points are allowed\\
 exitBlock(<em>c</em>) & Defines an exit at the current position. 
 The cellset <em>c</em> represents the live-out information \\
 pseudOp(<em>p</em>)  & Emits an pseudo op <em>p</em> at the current position \\
 emitInstr(<em>i</em>)  & Emits an instruction <em>i</em> at the current position \\
 blockName(<em>b</em>) & Changes the block name to <em>b</em> \\
 comment(<em>msg</em>) & Emits a comment <em>msg</em> at the current position \\
 finish      & Signals that the use of the emitter is finished.
 The emitter is free to perform its post-processing functions.
 When this is finished the CFG is built. 

The functor <tt>ControlFlowGraphGenFn</tt> below can be
used to create a CFG builder that uses the <tt>CODE_EMITTER</tt> interface.
 signature <a href="../IR/mlrisc-cfg-gen.sig" target=code>CONTROL_FLOW_GRAPH_GEN</a> = sig
   structure CFG     : CONTROL_FLOW_GRAPH
   structure Emitter : CODE_EMITTER
       sharing Emitter.I = CFG.I
       sharing Emitter.P = CFG.P
   val emitter : CFG.cfg -> Emitter.emitter
 functor <a href="../IR/mlrisc-cfg-gen.sml" target=code>ControlFlowGraphGenFn</a>
    (structure CFG     : CONTROL_FLOW_GRAPH
     structure Emitter : CODE_EMITTER
     structure P       : INSN_PROPERTIES
         sharing CFG.I = Emitter.I = P.I
         sharing CFG.P = Emitter.P
         sharing CFG.B = Emitter.B

\paragraph{Cluster to CFG}

The core \MLRISC{} system implements many instruction selection
front-ends.  The result of an instruction selection module is a linear 
code layout block called a cluster.  The functor <tt>Cluster2CFGFn</tt> below 
generates a translator that translates a cluster into a CFG:
 signature <a href="../IR/mlrisc-cluster2cfg.sig" target=code>CLUSTER2CFG</a> = sig
   structure F   : FLOWGRAPH
      sharing CFG.I = F.I
      sharing CFG.P = F.P
      sharing CFG.B = F.B
   val cluster2cfg : F.cluster -> CFG.cfg
 functor <a href="../IR/mlrisc-cluster2cfg.sml" target=code>Cluster2CFGFn</a>
   (structure CFG : CONTROL_FLOW_GRAPH 
    structure F   : FLOWGRAPH
    structure P   : INSN_PROPERTIES
       sharing CFG.I = F.I = P.I 
       sharing CFG.P = F.P
       sharing CFG.B = F.B

\paragraph{CFG to Cluster}

The basic \MLRISC{} system also implements many back-end functions
such as register allocation, assembly output and machine code output.
These modules all utilize the cluster representation.  The 
functor <a href="../IR/mlrisc-cfg2cluster.sml" target=code>CFG2ClusterFn</a> 
below generates a translator
that converts a CFG into a cluster.  With the previous functor,
the CFG and the cluster presentation can be freely inter-converted.
 signature <a href="../IR/mlrisc-cfg2cluster.sig" target=code>CFG2CLUSTER</a> = sig
   structure F   : FLOWGRAPH
      sharing CFG.I = F.I
      sharing CFG.P = F.P
      sharing CFG.B = F.B
   val cfg2cluster : { cfg : CFG.cfg, relayout : bool } -> F.cluster
 functor <a href="../IR/mlrisc-cfg2cluster.sml" target=code>CFG2ClusterFn</a>
   (structure CFG  : CONTROL_FLOW_GRAPH
    structure F    : FLOWGRAPH
       sharing CFG.I = F.I
       sharing CFG.P = F.P
       sharing CFG.B = F.B
    val patchBranch : {instr:CFG.I.instruction, backwards:bool} -> 
                         CFG.I.instruction list

When a CFG originates from a cluster, we try to preserve
the same code layout through out all optimizations when possible.
The function <tt>cfg2cluster</tt> takes an optional flag 
that specifies we should force the recomputation of
the code layout of a control flow graph when translating a CFG
back into a cluster.

<h3>Basic CFG Transformations</h3>

Basic CFG transformations are implemented in the functor 
<tt>CFGUtilFn</tt>.  These transformations include splitting edges, merging
edges, removing unreachable code and tail duplication.
   functor <a href="../IR/mlrisc-cfg-util.sml" target=code>CFGUtilFn</a>
      (structure CFG : CONTROL_FLOW_GRAPH
       structure P   : INSN_PROPERTIES
          sharing P.I = CFG.I
      ) : CFG_UTIL

The signature of <tt>CFGUtilFn</tt> is defined below:
 signature <a href="../IR/mlrisc-cfg-util.sig" target=code>CFG_UTIL</a> = sig
    structure CFG : CONTROL_FLOW_GRAPH
    val updateJumpLabel : CFG.cfg -> node_id -> unit
    val mergeEdge       : CFG.cfg -> CFG.edge -> bool
    val eliminateJump   : CFG.cfg -> node_id -> bool
    val insertJump      : CFG.cfg -> node_id -> bool
    val splitEdge  : CFG.cfg -> { edge : CFG.edge, jump : bool }
                      -> { edge : CFG.edge, node : CFG.node }
    val isMerge        : CFG.cfg -> node_id -> bool
    val isSplit        : CFG.cfg -> node_id -> bool
    val hasSideExits   : CFG.cfg -> node_id -> bool
    val isCriticalEdge : CFG.cfg -> CFG.edge -> bool
    val splitAllCriticalEdges : CFG.cfg -> unit
    val ceed : CFG.cfg -> node_id * node_id -> bool
    val tailDuplicate : CFG.cfg -> { subgraph : CFG.cfg, root : node_id } 
                                -> { nodes : CFG.node list, 
                                     edges : CFG.edge list } 
    val removeUnreachableCode : CFG.cfg -> unit
    val mergeAllEdges : CFG.cfg -> unit

These functions perform the following functions:
  <li>  <tt>updateJumpLabel</tt> <em>G u</em>.  This function
     updates the label of the branch instruction in a block <em>u</em>
     to be consistent with the control flow edges with source <em>u</em>.  
     This is an nop if the CFG is already consistent. 
  <li> <tt>mergeEdge</tt> <em>G e</em>. This function merges edge <em>e \equiv u \edge{} v</em>
        in the graph <em>G</em> if possible.   This is successful only if
        there are no other edges flowing into <em>v</em> and no other edges
        flowing out from <em>u</em>.  It returns true if the merge
        operation is successful.  If successful, the nodes <em>u</em> and <em>v</em>
        will be coalesced into the block <em>u</em>.   The jump instruction (if any)
        in the node <em>u</em> will also be elided.
  <li> <tt>eliminateJump</tt> <em>G u</em>.  This function eliminate the
      jump instruction at the end of block <em>u</em> if it is feasible.
  <li> <tt>insertJump</tt> <em>G u</em>.  This function inserts a jump
       instruction in block <em>u</em> if it is feasible.
  <li> <tt>splitEdge</tt> <em>G e</em>.  This function 
     split the control flow edge <em>e</em>, and return a new edge <em>e'</em> and the 
     new block <em>u</em> as return values.  It addition, it takes as
     argument a flag <tt>jump</tt>.  If this flag is true, 
     then a jump instruction is always placed in the 
     split; otherwise, we try to eliminate the jump when feasible.
  <li> <tt>isMerge</tt> <em>G u</em>.  This function tests whether block <em>u</em>
          is a <font color="#ff0000">merge</font> node.  A merge node is a node that
          has two or more incoming flow edges.
  <li> <tt>isSplit</tt> <em>G u</em>.  This function tests whether block <em>u</em>
           is a <font color="#ff0000">split</font> node.  A split node is a node that
            has two or more outgoing flow edges.
  <li> <tt>hasSideExits</tt> <em>G u</em>.  This function tests whether
           a block has side exits <em>G</em>.  This assumes that <em>u</em>
           is a hyperblock.
  <li> <tt>isCriticalEdge</tt> <em>G e</em>.  This function tests whether
      the edge <em>e</em> is a <font color="#ff0000">critical</font> edge.  The 
       edge <em>e \equiv u \edge{} v</em> is critical iff 
      there are <em>u</em> is merge node and <em>v</em> is a split node.
  <li>  <tt>splitAllCriticalEdges</tt> <em>G</em>.  This function goes
        through the CFG <em>G</em> and splits
      all critical edges in the CFG.
      This can introduce extra jumps and basic blocks in the program.
  <li>  <tt>mustPreceed</tt> <em>G (u,v)</em>.   This function
      checks whether two blocks <em>u</em> and <em>v</em> are necessarily adjacent.
      Blocks <em>u</em> and <em>v</em> must be adjacent iff <em>u</em> must preceed <em>v</em>
      in any feasible code layout.
  <li>  <tt>tailDuplicate</tt>.  
    val tailDuplicate : CFG.cfg -> { subgraph : CFG.cfg, root : node_id } 
                                -> { nodes : CFG.node list, 
                                     edges : CFG.edge list } 
%\begin{tabular}{|c|} \hline
\caption{\label{fig:tail-duplication} Tail-duplication}

      This function tail-duplicates the region <tt>subgraph</tt>
      until it only has a single entry <tt>root</tt>.
      Return the set of new nodes and new edges.  
      The region is represented as a subgraph view of the CFG.
      Figure~\ref{fig:tail-duplication} illustrates 
      this transformation.

  <li>  <tt>removeUnreachableCode</tt> <em>G</em>. This function
          removes all unreachable code  from the graph.
  <li>  <tt>mergeAllEdges</tt> <em>G</em>.  This function tries to merge all
         the edges in the flowgraph <em>G</em>.  Merging is performed in the
         non-increasing order of edge frequencies. 

<h3>Dataflow Analysis</h3>
MLRISC provides a simple customizable module for performing
iterative dataflow analysis.   A dataflow analyzer
has the following signature:

 signature <a href="../IR/dataflow.sig" target=code>DATAFLOW_ANALYZER</a> = sig
   type dataflow_info
   val analyze : CFG.cfg * dataflow_info -> dataflow_info

A dataflow problem is described by the signature <tt>DATAFLOW_PROBLEM</tt>, 
described below:
 signature <a href="../IR/dataflow.sig" target=code>DATAFLOW_PROBLEM</a> = sig
   type domain
   type dataflow_info
   val forward   : bool
   val bot       : domain
   val ==        : domain * domain -> bool
   val join      : domain list -> domain
   val prologue  : CFG.cfg * dataflow_info ->
                       CFG.block node ->
                           { input    : domain,
                             output   : domain,
                             transfer : domain -> domain
   val epilogue  : CFG.cfg * dataflow_info ->
                       { node   : CFG.block node,
                         input  : domain,
                         output : domain
                       } -> unit
This description contains the following items
<li> <tt>type domain</tt> is the abstract lattice domain <em>D</em>.
<li> <tt>type dataflow_info</tt> is where the dataflow information
is stored.
<li> <tt>forward</tt> is true iff the dataflow problem is in the
forward direction
<li> <tt>bot</tt> is the bottom element of <em>D</em>.
<li> <tt>==</tt> is the equality function on <em>D</em>.
<li> <tt>join</tt> is the least-upper-bound function on <em>D</em>.
<li> <tt>prologue</tt> is a user-supplied function that performs
pre-processing and setup.  For each CFG node <em>X</em>, this function
 <li>  <tt>input</tt> -- which is the initial input value of <em>X</em>
 <li> <tt>output</tt> -- which is the initial output value of <em>X</em>
 <li> <tt>transfer</tt> -- which is the transfer function on <em>X</em>.
<li> <tt>epilogue</tt> is a function that performs post-processing.
It visits each node <em>X</em> in the flowgraph and return the resulting
<tt>input</tt> and <tt>output</tt> value for <em>X</em>. 

To generate a new dataflow analyzer from a dataflow problem, 
the functor <tt>DataflowFn</tt> can be used:
 functor <a href="../IR/dataflow.sml" target=code>DataflowFn</a>(P : DATAFLOW_PROBLEM) : DATAFLOW_ANALYZER =

<h3>Static Branch Prediction</h3> 

<h3>Branch Optimizations </h3>

    <FONT SIZE="-2">
<A HREF="mailto:leunga@cs.nyu.edu">Allen Leung</A></ADDRESS>


ViewVC Help
Powered by ViewVC 1.0.0