[GHC] #8456: Control flow optimisations duplicate blocks

[GHC]

#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/95938fc84b4310cb04383594db35ce7ae15820c7/compiler/cmm/CmmContFlowOpt.hs#L127
 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