[GHC] #9388: Narrow the scope of the notorious "state hack"

[GHC]

#9388: Narrow the scope of the notorious "state hack"
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by nomeata):

 I gave it a shot. The obvious place to make the demand analyzer believe
 that something of type `IO` is going to be called at most once is by
 adjusting `body_dmd` in `dmdAnalRhs`, similarly to `[Product demands for
 function body]`.

 The branch `wip/T9388` contains patches that remove the old state hack and
 introduce this one.

 On first glance, it seems to work. At least the bug in #10102 does not
 occur any more.

 Overall, it has a negative effect on performance (at least on bytes
 allocated): nofib’s `fibheaps` regresses by `16.7%`, `banner` by `12.4%`
 and `hpg` by `7.1%`, rewrite by `5.8%`. Others improve: `k-nucleotide` by
 `5%`. Geometric mean is a regression by `0.4%`. A quick diff of fibheap’s
 core shows large changes, which I did not investigate further.

 The branch validates, with the exception of a number of compiler
 performance benchmarks (T9203 haddock.Cabal haddock.base T5030 T5631
 T9872c T9872a T5642 T9020 T3064 T9872d T9872b T1969), where allocation
 increases by up to 30%. So real world programs run better with the old
 state hack.

 In a way that is expected: Eta expansion is usually a good thing, even if
 cannot see that a the lambda is indeed one-shot. And even if it is not
 really one-shot, the benefits of eta-expansion might, in some cases,
 outweigh the cost of lost sharing. Only in a few (uncommon?) cases, e.g.
 replicate with a large number, it really hurts.

 I’m surprised that no test case starts to fail, and no known-to-fail test
 case suddenly passes; it seems that we have little coverage on the desired
 and/or unwanted effects of the state hack.

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