#8456: Control flow optimisations duplicate blocks --------------------------------------------+------------------------------ Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8275 | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by jstolarek): I have rewritten `maybe_concat` function and some subsequent functions - code is [https://github.com/jstolarek/ghc/blob/95938fc84b4310cb04383594db35ce7ae15820... here on github]. In the modified algorithm I maintain an up-to-date map of predecessors. I don't like the idea of having an approximation - up till now we had an approximation (i.e. changing number of predecessors usually doesn't matter) and now we're fixing it because it does the wrong thing. Having an approximation just feels dangerous. My patch validates, except for the fact that it slightly increases allocation and trips two performance tests. I think that's to be expected, given that we are passing around one more data structure and updating it. I'll be updating the comments for the next hour or so, so if there's something wrong or unclear about the patch please tell me. As a side note I see some recurring problems in the design of Cmm pipeline: * here we have a problem, because we create a list of predecessors, which we use to perform graph transformations but at the same time we invalidate that list * in #8205 we computed a list of proc-points and passed it to stack layout, which needed it for graph transformations but at the same time invalidated that list * !CmmContFlowOpt creates unreachable blocks and relies on common block elimination to remove them * stack layout creates unreachable blocks and relies on sinking pass to remove them The last two have not manifested themselves as bugs, but fall into the category of introducing inconsistencies in our data and assuming that someone will later clean up those inconsistencies. I will not be surprised if more such problems are lurking in the code. At the moment I don't know how to do better, but certainly the current design feels tightly coupled and that is not a good thing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8456#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler