Dataflow analysis for Cmm

[Jan Stolarek]

Michał,

Dataflow module could indeed use cleanup. I have made two attempts at this in the past but I don't 
think any of them was merged - see [1] and [2]. [2] was mostly type-directed simplifications. It 
would be nice to have this included in one form or another. It sounds like you also have a more 
in-depth refactoring in mind. Personally as long as it is semantically correct I think it will be 
a good thing. I would especially support removing dead code that we don't really use.

[1] https://github.com/jstolarek/ghc/commits/js-hoopl-cleanup-v2
[2] https://github.com/jstolarek/ghc/commits/js-hoopl-cleanup-v2

> Second question: how could we merge this? (...)
I'm not sure if I understand. The end result after merging will be exactly the same, right? Are 
you asking for advice what is the best way of doing this from a technical point if view? I would 
simply edit the existing module. Introducing a temporary second module seems like unnecessary 
extra work and perhaps complicating the patch review.

> I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s
> the recommended workflow for code that’s not ready for review…
This is OK but please remember to set status of revision to "Planned changes" after uploading it 
to Phab so it doesn't sit in reviewing queue.

Janek

Dnia niedziela, 16 października 2016, Michal Terepeta napisał:
> 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.
>   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).
>   - More flexible (e.g., the clients could know which block they’re
> processing;
>     we could consider memoizing some per block information, etc.).
>
> What do you think about this?
>
> I have a branch that implements the above:
> https://github.com/michalt/ghc/tree/dataflow2/1
> It’s introducing a second parallel implementation (`cmm.Hoopl.Dataflow2`
> module), so that it's possible to run ./validate while comparing the
> results of
> the old implementation with the new one.
>
> Second question: how could we merge this? (assuming that people are
> generally
> ok with the approach) Some ideas:
> - Change cmm/Hoopl/Dataflow module itself along with the three analyses
> that use
>   it in one step.
> - Introduce the Dataflow2 module first, then switch the analyses, then
> remove
>   any unused code that still depends on the old Dataflow module, finally
> remove
>   the old Dataflow module itself.
> (Personally I'd prefer the second option, but I'm also ok with the first
> one)
>
> I’m happy to export the code to Phab if you prefer - I wasn’t sure what’s
> the
> recommended workflow for code that’s not ready for review…
>
> Thanks,
> Michal


 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual to whom it is addressed. 
If you are not the intended recipient or if you have received this message in error, 
please notify the sender and delete it from your system.