#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