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.