<div dir="ltr"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Hi,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I was looking at cleaning up a bit the situation with dataflow analysis for Cmm.</div><div class="gmail_msg">In particular, I was experimenting with rewriting the current</div><div class="gmail_msg">`cmm.Hoopl.Dataflow` module:</div><div class="gmail_msg">- To only include the functionality to do analysis (since GHC doesn’t seem to use</div><div class="gmail_msg">  the rewriting part).</div><div class="gmail_msg">  Benefits:</div><div class="gmail_msg">  - Code simplification (we could remove a lot of unused code).</div><div class="gmail_msg">  - Makes it clear what we’re actually using from Hoopl.</div><div class="gmail_msg">- To have an interface that works with transfer functions operating on a whole</div><div class="gmail_msg">  basic block (`Block CmmNode C C`).</div><div class="gmail_msg">  This means that it would be up to the user of the algorithm to traverse the</div><div class="gmail_msg">  whole block.</div><div class="gmail_msg">  Benefits:</div><div class="gmail_msg">  - Further simplifications.</div><div class="gmail_msg">  - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a copy&paste</div><div class="gmail_msg">    of `analyzeFwd` but ignores the middle nodes (probably for efficiency of</div><div class="gmail_msg">    analyses that only look at the blocks).</div><div class="gmail_msg">  - More flexible (e.g., the clients could know which block they’re processing;</div><div class="gmail_msg">    we could consider memoizing some per block information, etc.).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What do you think about this?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I have a branch that implements the above:</div><div class="gmail_msg"><a href="https://github.com/michalt/ghc/tree/dataflow2/1" class="gmail_msg" target="_blank">https://github.com/michalt/ghc/tree/dataflow2/1</a></div><div class="gmail_msg">It’s introducing a second parallel implementation (`cmm.Hoopl.Dataflow2`</div><div class="gmail_msg">module), so that it's possible to run ./validate while comparing the results of</div><div class="gmail_msg">the old implementation with the new one.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Second question: how could we merge this? (assuming that people are generally</div><div class="gmail_msg">ok with the approach) Some ideas:</div><div class="gmail_msg">- Change cmm/Hoopl/Dataflow module itself along with the three analyses that use</div><div class="gmail_msg">  it in one step.</div><div class="gmail_msg">- Introduce the Dataflow2 module first, then switch the analyses, then remove</div><div class="gmail_msg">  any unused code that still depends on the old Dataflow module, finally remove</div><div class="gmail_msg">  the old Dataflow module itself.</div><div class="gmail_msg">(Personally I'd prefer the second option, but I'm also ok with the first one)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s the</div><div class="gmail_msg">recommended workflow for code that’s not ready for review…</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks,</div><div class="gmail_msg">Michal<br class="gmail_msg"></div></div><div class="gmail_msg"><br class="gmail_msg"></div></div></div>