[GHC] #10124: Simple case analyses generate too many branches

[GHC]

#10124: Simple case analyses generate too many branches
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  #6135,            |  Differential Revisions:
  #9661,#10137                       |
-------------------------------------+-------------------------------------

Comment (by Joachim Breitner <mail@…>):

 In [changeset:"de1160be047790afde4ec76de0a81ba3be0c73fa/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="de1160be047790afde4ec76de0a81ba3be0c73fa"
 Refactor the story around switches (#10137)

 This re-implements the code generation for case expressions at the Stg →
 Cmm level, both for data type cases as well as for integral literal
 cases. (Cases on float are still treated as before).

 The goal is to allow for fancier strategies in implementing them, for a
 cleaner separation of the strategy from the gritty details of Cmm, and
 to run this later than the Common Block Optimization, allowing for one
 way to attack #10124. The new module CmmSwitch contains a number of
 notes explaining this changes. For example, it creates larger
 consecutive jump tables than the previous code, if possible.

 nofib shows little significant overall improvement of runtime. The
 rather large wobbling comes from changes in the code block order
 (see #8082, not much we can do about it). But the decrease in code size
 alone makes this worthwhile.

 ```
         Program           Size    Allocs   Runtime   Elapsed  TotalMem
             Min          -1.8%      0.0%     -6.1%     -6.1%     -2.9%
             Max          -0.7%     +0.0%     +5.6%     +5.7%     +7.8%
  Geometric Mean          -1.4%     -0.0%     -0.3%     -0.3%     +0.0%
 ```

 Compilation time increases slightly:
 ```
         -1 s.d.                -----            -2.0%
         +1 s.d.                -----            +2.5%
         Average                -----            +0.3%
 ```

 The test case T783 regresses a lot, but it is the only one exhibiting
 any regression. The cause is the changed order of branches in an
 if-then-else tree, which makes the hoople data flow analysis traverse
 the blocks in a suboptimal order. Reverting that gets rid of this
 regression, but has a consistent, if only very small (+0.2%), negative
 effect on runtime. So I conclude that this test is an extreme outlier
 and no reason to change the code.

 Differential Revision: https://phabricator.haskell.org/D720
 }}}

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