Changes between Version 11 and Version 12 of Hoopl/Cleanup


Ignore:
Timestamp:
Aug 22, 2013 5:33:36 PM (2 years 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).