Dataflow analysis for Cmm

[Michal Terepeta]

On Fri, Oct 21, 2016 at 4:04 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On 16 October 2016 at 14:03, Michal Terepeta <michal.terepeta at gmail.com>
> wrote:
>
> Hi,
>
> I was looking at cleaning up a bit the situation with dataflow analysis
> for Cmm.
> In particular, I was experimenting with rewriting the current
> `cmm.Hoopl.Dataflow` module:
> - To only include the functionality to do analysis (since GHC doesn’t seem
> to use
>   the rewriting part).
>   Benefits:
>   - Code simplification (we could remove a lot of unused code).
>   - Makes it clear what we’re actually using from Hoopl.
> - To have an interface that works with transfer functions operating on a
> whole
>   basic block (`Block CmmNode C C`).
>   This means that it would be up to the user of the algorithm to traverse
> the
>   whole block.
>
>
> 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.
>

Right, I've also seen:
https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance
but it seems that there weren't any follow-ups/conclusions on that.
Also, I haven't started writing anything for the rewriting yet (only
analysis for
now).

Btw. I'm currently experimenting with the GHC's fork of Dataflow module -
and for now I'm not planning on pushing the changes to the upstream Hoopl.
There are already projects that depend on the current interface of Hoopl
(it's
on Hackage after all) and it's going to be hard to make certain changes
there.
Hope that's ok with everyone!
(also, we can always revisit this question later)

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)
>

Thanks for saying that!


>   Benefits:
>   - Further simplifications.
>   - We could remove `analyzeFwdBlocks` hack, which AFAICS is just a
> copy&paste
>     of `analyzeFwd` but ignores the middle nodes (probably for efficiency
> of
>     analyses that only look at the blocks).
>
>
> Aren't we using this in dataflowAnalFwdBlocks, that's used by
> procpointAnalysis?
>

Yes, sorry for confusion! What I meant is that
analyzeFwdBlocks/dataflowAnalFwdBlocks is currently a special case of
analyzeFwd/dataflowAnalFwd that only looks at first and last nodes. So if we
move to block-oriented interface, it simply stops being a special case and
fits
the new interface (since it's the analysis that decides whether to look at
the
whole block or only parts of it). So it's removed in the sense of "removing
a
special case".

Cheers,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161024/1c908b31/attachment.html>