[GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration

[GHC]

#11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.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):  Phab:D2070
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 The performance regressions (have not looked at details yet) are very
 annyoing: My impression was that this change would not make a difference,
 i.e. the same one-shot annotations would be set, only in a slightly later
 phase (occurrence analyzer instead of demand analyzer). With the
 exception, of course, of wrongly set one-shot annotations; this is of
 course what we want to fix. So if this causes performance regressions,
 then it must have been the case that GHC was doing something to the code
 that was not solidly warranted (inlined into a lambda that was not
 guaranteed to be one-shot) and could have gone wrong, but indeed improved
 matters (either because the lambda was one-shot after all, or the
 duplicated work was less than the benefits of inlining).

 So by fixing a bug, we reduce performance. Reminds me awful lot of trying
 to make the state hack less aggressive. There is collateral damage.

 Also, there were some improvements, so in some cases, GHC did make a bold,
 unwarranted change to the code and it indeed went wrong.

 So I guess the proper thing to do is to look at all the regressions and
 decide whether we can improve the compiler in other ways to make this
 work, before being allowed to push this bug fix. How tedious, especially
 with performance regressions in the compiler.

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