Changes between Version 1 and Version 2 of Hoopl/Cleanup


Ignore:
Timestamp:
Aug 22, 2013 12:29:06 PM (8 months ago)
Author:
jstolarek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Hoopl/Cleanup

    v1 v2  
    33''This page was created in August 2013 as a temporary place to store proposals about cleaning up Hoopl library. After these changes are implemented we should replace this page with either another page or a Note in the source code that would explain current design of Hoopl.'' 
    44 
    5 Me (Jan Stolarek, JS) and Simon PJ had some discussion recently about cleaning up Hoopl to make its interface more consistent and less confusing  
     5Me (Jan Stolarek, JS) and Simon PJ recently had some discussion about cleaning up Hoopl to make its interface more consistent and less confusing. Here are some of the key proposals and ideas: 
    66 
    7 Can we be explicit about which join situations can occur inside hoopl? 
     7  * forward and backward analyses are not dual, but current Hoopl interface does not reflect that in any way. Here's a description of how these passes work currently and how we could modify them:[[BR]] 
     8     * all analysis and rewrite passes defined in `compiler/cmm/Hoopl/Dataflow.hs` take as a parameters a list of entry points to the graph and a list of known facts. These passes are called from the wrappers defined in `compiler/cmm/CmmUtils.hs`, which pass entry point to the graph (`JustC [entry]`) as a list of entry points and a list of facts given by the user. It is possible for a user to pass an empty list of known facts. 
     9     * we use `getFact` (`compiler/cmm/Hoopl/Dataflow.hs`) function to look up facts about analyzed blocks:[[BR]] 
     10{{{-- Fact lookup: the fact `orelse` bottom 
     11getFact  :: DataflowLattice f -> Label -> FactBase f -> f 
     12getFact lat l fb = case lookupFact l fb of Just  f -> f 
     13                                           Nothing -> fact_bot lat 
     14}}}[[BR]] 
     15     * in forward analysis, if user passes in facts about entry points to the graph, then we don't need `fact_bot` field of `DataflowLattice`, because we will always have some fact about analysed block. What a user needs to pass is `[(L,F)]`, where `L` is type of label of an entry point and `F` is a type of fact. But now, if the user provides a list of fact about every entry label then we don't need to pass separately a list of entry points to the graph. 
     16     * in backward analysis we start from the exit points of the graph, but cannot know any facts about these points. This means that user needs to supply a list of entry labels `[L]`, which are used to determine a list of live blocks in a graph. But we have to supply a bottom element `F`, which will be default initial value for every starting point in backward analysis. 
     17  * Simon doesn't like the `joinInFacts` function, which is only called to possibly produce some debugging output from the join function. 
    818 
    919== A personal note by Jan Stolarek 
     
    2333''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?'' 
    2434 
    25 I think this question resulted from Hoopl's current behaviour where it sometimes ignores bottom passed in b y the user and sometimes does not. 
     35I think this question resulted from Hoopl's current behaviour where it sometimes ignores bottom passed in by the user and sometimes does not. 
    2636 
    2737When I did copy propagation pass I had data type that looked like this: