<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 October 2016 at 14:03, Michal Terepeta <span dir="ltr"><<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg">Hi,</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">I was looking at cleaning up a bit the situation with dataflow analysis for Cmm.</div><div class="m_-3332057552796876623gmail_msg">In particular, I was experimenting with rewriting the current</div><div class="m_-3332057552796876623gmail_msg">`cmm.Hoopl.Dataflow` module:</div><div class="m_-3332057552796876623gmail_msg">- To only include the functionality to do analysis (since GHC doesn’t seem to use</div><div class="m_-3332057552796876623gmail_msg">  the rewriting part).</div><div class="m_-3332057552796876623gmail_msg">  Benefits:</div><div class="m_-3332057552796876623gmail_msg">  - Code simplification (we could remove a lot of unused code).</div><div class="m_-3332057552796876623gmail_msg">  - Makes it clear what we’re actually using from Hoopl.</div><div class="m_-3332057552796876623gmail_msg">- To have an interface that works with transfer functions operating on a whole</div><div class="m_-3332057552796876623gmail_msg">  basic block (`Block CmmNode C C`).</div><div class="m_-3332057552796876623gmail_msg">  This means that it would be up to the user of the algorithm to traverse the</div><div class="m_-3332057552796876623gmail_msg">  whole block.</div></div></div></div></blockquote><div><br></div><div>Ah! This is actually something I wanted to do but didn't get around to.  When I was working on the code generator I found that using Hoopl for rewriting was prohibitively slow, which is why we're not using it for anything right now, but I think that pulling out the basic block transformation is possibly a way forwards that would let us use Hoopl.<br><br></div><div>A lot of the code you're removing is my attempt at "optimising" the Hoopl dataflow algorithm to make it usable in GHC.  (I don't mind removing this, it was a failed experiment really)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg">  Benefits:</div><div class="m_-3332057552796876623gmail_msg">  - Further simplifications.</div><div class="m_-3332057552796876623gmail_msg">  - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a copy&paste</div><div class="m_-3332057552796876623gmail_msg">    of `analyzeFwd` but ignores the middle nodes (probably for efficiency of</div><div class="m_-3332057552796876623gmail_msg">    analyses that only look at the blocks).</div></div></div></div></blockquote><div><br></div><div>Aren't we using this in dataflowAnalFwdBlocks, that's used by procpointAnalysis?<br></div><div> <br></div><div>Cheers<br></div><div>Simon<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg"><div class="m_-3332057552796876623gmail_msg">  - More flexible (e.g., the clients could know which block they’re processing;</div><div class="m_-3332057552796876623gmail_msg">    we could consider memoizing some per block information, etc.).</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">What do you think about this?</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">I have a branch that implements the above:</div><div class="m_-3332057552796876623gmail_msg"><a href="https://github.com/michalt/ghc/tree/dataflow2/1" class="m_-3332057552796876623gmail_msg" target="_blank">https://github.com/michalt/<wbr>ghc/tree/dataflow2/1</a></div><div class="m_-3332057552796876623gmail_msg">It’s introducing a second parallel implementation (`cmm.Hoopl.Dataflow2`</div><div class="m_-3332057552796876623gmail_msg">module), so that it's possible to run ./validate while comparing the results of</div><div class="m_-3332057552796876623gmail_msg">the old implementation with the new one.</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">Second question: how could we merge this? (assuming that people are generally</div><div class="m_-3332057552796876623gmail_msg">ok with the approach) Some ideas:</div><div class="m_-3332057552796876623gmail_msg">- Change cmm/Hoopl/Dataflow module itself along with the three analyses that use</div><div class="m_-3332057552796876623gmail_msg">  it in one step.</div><div class="m_-3332057552796876623gmail_msg">- Introduce the Dataflow2 module first, then switch the analyses, then remove</div><div class="m_-3332057552796876623gmail_msg">  any unused code that still depends on the old Dataflow module, finally remove</div><div class="m_-3332057552796876623gmail_msg">  the old Dataflow module itself.</div><div class="m_-3332057552796876623gmail_msg">(Personally I'd prefer the second option, but I'm also ok with the first one)</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s the</div><div class="m_-3332057552796876623gmail_msg">recommended workflow for code that’s not ready for review…</div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div><div class="m_-3332057552796876623gmail_msg">Thanks,</div><div class="m_-3332057552796876623gmail_msg">Michal<br class="m_-3332057552796876623gmail_msg"></div></div><div class="m_-3332057552796876623gmail_msg"><br class="m_-3332057552796876623gmail_msg"></div></div></div>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div></div>