X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=compiler%2Fcmm%2FZipCfg.hs;h=ec2368fb57781c10058ca6448a521ee6cdf0c56a;hb=f74d318db9db0b95eb4f41e29a3bea43097ae9d5;hp=b3973db7c8f422e8e9dc5f62167919041c17fa2e;hpb=4559ed114a3c16ee6840abc503c5438d799505f1;p=ghc-hetmet.git

diff --git a/compiler/cmm/ZipCfg.hs b/compiler/cmm/ZipCfg.hs
index b3973db..ec2368f 100644
--- a/compiler/cmm/ZipCfg.hs
+++ b/compiler/cmm/ZipCfg.hs
@@ -1,8 +1,7 @@
 {-# LANGUAGE ScopedTypeVariables #-}
 module ZipCfg
     ( 	-- These data types and names are carefully thought out
-      BlockId(..), freshBlockId		-- ToDo: BlockId should be abstract,
-					--	 but it isn't yet
+      BlockId(..) 	-- ToDo: BlockId should be abstract, but it isn't yet
     , BlockEnv, emptyBlockEnv, lookupBlockEnv, extendBlockEnv, insertBlock, mkBlockEnv
     , BlockSet, emptyBlockSet, elemBlockSet, extendBlockSet, mkBlockSet
     , Graph(..), LGraph(..), FGraph(..)
@@ -44,7 +43,6 @@ import Panic
 import Unique
 import UniqFM
 import UniqSet
-import UniqSupply
 
 import Maybe
 import Prelude hiding (zip, unzip, last)
@@ -100,13 +98,13 @@ increasing complexity, they are:
 There are three types because each type offers a slightly different
 invariant or cost model.  
 
-  * The distinguished entry of a Graph has no label.  Because labels must
-    be unique, acquiring one requires a monadic operation ('freshBlockId').
-    The primary advantage of the Graph representation is that we can build
-    a small Graph purely functionally, without entering a monad.  For
-    example, during optimization we can easily rewrite a single middle
-    node into a Graph containing a sequence of two middle nodes followed by
-    LastExit.
+  * The distinguished entry of a Graph has no label.  Because labels must be
+    unique, acquiring one requires a supply of Unique labels (BlockId's).
+    The primary advantage of the Graph representation is that we can build a
+    small Graph purely functionally, without needing a fresh BlockId or
+    Unique.  For example, during optimization we can easily rewrite a single
+    middle node into a Graph containing a sequence of two middle nodes
+    followed by LastExit.
 
   * In an LGraph, every basic block is labelled.  The primary advantage of
     this representation is its simplicity: each basic block can be treated
@@ -168,11 +166,6 @@ data FGraph m l = FGraph { fg_entry  :: BlockId
 
 ----  Utility functions ---
 
--- | The string argument to 'freshBlockId' was originally helpful in debugging the Quick C--
--- compiler, so I have kept it here even though at present it is thrown away at
--- this spot---there's no reason a BlockId couldn't one day carry a string.
-freshBlockId :: String -> UniqSM BlockId
-
 blockId   :: Block  m l -> BlockId
 zip       :: ZBlock m l -> Block  m l
 unzip     :: Block  m l -> ZBlock m l
@@ -274,6 +267,8 @@ fold_blocks :: (Block m l -> a -> a) -> a -> LGraph m l -> a
 map_nodes :: (BlockId -> BlockId) -> (m -> m') -> (l -> l') -> LGraph m l -> LGraph m' l'
    -- mapping includes the entry id!
 
+map_blocks :: (Block m l -> Block m' l') -> LGraph m' l' -> LGraph m' l'
+
 -- | These translation functions are speculative.  I hope eventually
 -- they will be used in the native-code back ends ---NR
 translate :: (m          -> UniqSM (LGraph m' l')) ->
@@ -336,8 +331,6 @@ instance LastNode l => HavingSuccessors (ZTail m l) where
 
 blockId (Block id _) = id
 
-freshBlockId _ = do { u <- getUniqueUs; return $ BlockId u }
-
 -- | Convert block between forms.
 -- These functions are tail-recursive, so we can go as deep as we like
 -- without fear of stack overflow.  
@@ -508,6 +501,8 @@ fold_layout f z g@(LGraph eid _) = fold (postorder_dfs g) z
 
 -- | The rest of the traversals are straightforward
 
+map_blocks f (LGraph eid blocks) = LGraph eid (mapUFM f blocks)
+
 map_nodes idm middle last (LGraph eid blocks) = LGraph (idm eid) (mapUFM block blocks)
     where block (Block id t) = Block (idm id) (tail t)
           tail (ZTail m t) = ZTail (middle m) (tail t)