[GHC] #8326: Place heap checks common in case alternatives before the case

[GHC]

#8326: Place heap checks common in case alternatives before the case
-------------------------------------+-------------------------------------
        Reporter:  jstolarek         |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.7
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:  8317
 Related Tickets:  #1498             |  Differential Rev(s):  Phab:D343
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AndreasK):

 Replying to [comment:42 michalt]:
 > What is the status of this ticket?
 >
 > I've tried the patch suggested in comment:34, but my results of nofib
 were quite different, with some clear regressions (below I've removed
 anything where the difference was <2%)

 >
 > NOTE: I don't have much experience with investigations like this, so the
 whole analysis might be quite wrong. ;) Please let me know if something
 seems off. I'll attach the dump of STG/cmm/asm from both versions of
 `k-nucleotide` (with and without the patch).

 When I experimented with the order in which we generate uniques I also got
 a regression of ~18% for one of the shootout benchmarks, I think it was
 k-nucleotide but could have been another one.

 So while I don't doubt that there is a regression for k-nucleotide with
 this patch it doesn't have to be because the code we generate is worse for
 the general case. One really has to look at the Asm/Cmm for that.

 > it is not clear to me what to do if we have combination of the above
 (more than one branch that allocates heap and at least one branch that
 does not).

 In the long run we should do some static analysis to help us determine the
 hot code path.
 Eg distinguish between:
 * Alternatives leading to recursion
 * Alternatives being called once.
 * Bottoming alternatives.

 There are some ideas and work on that in #14672.

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