Changes between Version 11 and Version 12 of Hoopl/Cleanup


Ignore:
Timestamp:
Aug 22, 2013 5:33:36 PM (8 months ago)
Author:
jstolarek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Hoopl/Cleanup

    v11 v12  
    134134  * Jan doesn't like mess in Hoopl repo. There are unused modules (`Compiler.Hoopl.OldDataflow`, `Compiler.Hoopl.DataflowFold`), older versions of some modules (in `prototypes/` directory) or private correspondence with paper reviewers and between authors. 
    135135 
    136 == A personal note by Jan Stolarek 
    137  
    138 (I think this may be subsumed by the above.) 
    139  
    140 On my first contact with Hoopl I was very confused by some of its behaviour. Here's [http://www.haskell.org/pipermail/ghc-devs/2013-July/001757.html a question I mailed to ghc-devs on 13th July 2013]: 
    141  
    142 ''In my algorithm I need to initialize all of the blocks in a graph with bottom element of a lattice, except for the entry block, which needs some other initial values. I've written something like this:'' 
    143 {{{ 
    144 cmmCopyPropagation dflags graph = do 
    145     let entry_blk = g_entry graph 
    146     g' <- dataflowPassFwd graph [(entry_blk, (Top , Top))] $ 
    147             analRewFwd cpLattice cpTransfer cpRewrite 
    148     return . fst $ g' 
    149  
    150 cpLattice = DataflowLattice "copy propagation" (Bottom, Bottom) cpJoin 
    151 }}} 
    152 ''However, it seems that Bottom values passed to cpLattice are ignored - I could replace them with `undefined` and the code would still run without causing an error. Is there something obviously wrong in the way I pass initial fact values to dataflowPassFwd, or should I look for the problem in other parts of my code?'' 
    153  
    154 I think this question resulted from Hoopl's current behaviour where it sometimes ignores bottom passed in by the user and sometimes does not. 
    155  
    156 When I did copy propagation pass I had data type that looked like this: 
    157  
    158 {{{ 
    159 data Facts = Bottom | Const (M.Map a CPFact) 
    160 }}} 
    161  
    162 and I wrote `join` function which analyzed all four possible cases of joining facts: 
    163  
    164 {{{ 
    165 join (Const f) (Const f) = ... 
    166 join (Const f) Bottom    = ... 
    167 join Bottom    (Const f) = ... 
    168 join Bottom    Bottom    = ... 
    169 }}} 
    170  
    171 But only one of them was ever used actually. While I expected this for the last two ones and replaced them with compiler panic, I certainly did not expect that `join (Const f) Bottom` will not be used. Only after some tiresome debugging and analyzing the source code did I realize that Hoopl optimizes away this kind of join. I think that being explicit about the redundance of bottom in forward analysis will make Hoopl easier to use for newcommers. (Note: if I were doing backward analysis I would still need to analyze all four cases).