[GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks

[GHC]

#12915: cmmImplementSwitchPlans creates duplicate blocks
-------------------------------------+-------------------------------------
        Reporter:  alexbiehl         |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by michalt):

 @nomeata: Yes, we definitely don't want to move the sinking pass before
 stack layout. Stack layout can generate a lot of unnecessary stuff that
 the sinking pass removes. There's also a `Node [Sinking after stack
 layout]` that explains why we don't currently run sinking twice (before
 and after stack layout).

 As for the comment in code:

 {{{
  -- Any work storing block Labels must be performed _after_
  -- elimCommonBlocks
 }}}

 IIUC it refers to things like proc point analysis that stores the labels
 for later use (and since `elimCommonBlock` can remove blocks/labels, it
 might no longer be safe to use those results).

 Anyway, I did a quick experiment and modified `CmmPipeline`:
 - Added a call to `elimCommonBlocks` directly after the sinking pass.
 - Duplicated the proc point analysis so that the actual splitting uses up
 to date information.

 Results:
 - Binary size:
 {{{
         -1 s.d.                -----            -1.0%
         +1 s.d.                -----            -0.8%
         Average                -----            -0.9%
 }}}
 - Module sizes:
 {{{
         -1 s.d.                -----            -1.8%
         +1 s.d.                -----            +0.6%
         Average                -----            -0.6%
 }}}
 - Compile times:
 {{{
         -1 s.d.                -----            -1.6%
         +1 s.d.                -----            +3.3%
         Average                -----            +0.8%
 }}}
 - Compiler allocations:
 {{{
         -1 s.d.                -----            +0.3%
         +1 s.d.                -----            +1.0%
         Average                -----            +0.7%
 }}}
 Runtime didn't seem to change (there were some outliers in the 1-2% area,
 but I think that's just noise).

 So it seems that there is actually some potential to decrease binary size,
 but I'm not sure it's worth the compile time overhead.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12915#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler