<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Oct 21, 2016 at 4:04 PM Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On 16 October 2016 at 14:03, Michal Terepeta <span dir="ltr" class="gmail_msg"><<a href="mailto:michal.terepeta@gmail.com" class="gmail_msg" target="_blank">michal.terepeta@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">Hi,</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"><br class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"></div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">I was looking at cleaning up a bit the situation with dataflow analysis for Cmm.</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">In particular, I was experimenting with rewriting the current</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">`cmm.Hoopl.Dataflow` module:</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">- To only include the functionality to do analysis (since GHC doesn’t seem to use</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  the rewriting part).</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  Benefits:</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  - Code simplification (we could remove a lot of unused code).</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  - Makes it clear what we’re actually using from Hoopl.</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">- To have an interface that works with transfer functions operating on a whole</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  basic block (`Block CmmNode C C`).</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  This means that it would be up to the user of the algorithm to traverse the</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  whole block.</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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 class="gmail_msg"></div></div></div></div></blockquote><div><br></div><div><div>Right, I've also seen:</div><div><a href="https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R">https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R</a></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance</a></div><div>but it seems that there weren't any follow-ups/conclusions on that.</div><div>Also, I haven't started writing anything for the rewriting yet (only analysis for</div><div>now).</div><div><br></div><div>Btw. I'm currently experimenting with the GHC's fork of Dataflow module -</div><div>and for now I'm not planning on pushing the changes to the upstream Hoopl.</div><div>There are already projects that depend on the current interface of Hoopl (it's</div><div>on Hackage after all) and it's going to be hard to make certain changes there.</div></div><div>Hope that's ok with everyone!</div><div>(also, we can always revisit this question later)</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" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">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)</div></div></div></div></blockquote><div><br></div><div>Thanks for saying that!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg"><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  Benefits:</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  - Further simplifications.</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">  - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a copy&paste</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">    of `analyzeFwd` but ignores the middle nodes (probably for efficiency of</div><div class="m_-9063757261014815610m_-3332057552796876623gmail_msg gmail_msg">    analyses that only look at the blocks).</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Aren't we using this in dataflowAnalFwdBlocks, that's used by procpointAnalysis?</div></div></div></div></blockquote><div><br></div><div>Yes, sorry for confusion! What I meant is that</div><div>analyzeFwdBlocks/dataflowAnalFwdBlocks is currently a special case of</div><div>analyzeFwd/dataflowAnalFwd that only looks at first and last nodes. So if we</div><div>move to block-oriented interface, it simply stops being a special case and fits</div><div>the new interface (since it's the analysis that decides whether to look at the</div><div>whole block or only parts of it). So it's removed in the sense of "removing a</div><div>special case".</div><div> <br></div><div>Cheers,</div><div>Michal</div></div></div>