[GHC] #13379: Space leak / quadratic behavior when inlining

[GHC]

#13379: Space leak / quadratic behavior when inlining
-------------------------------------+-------------------------------------
        Reporter:  jberryman         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  Inlining
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13586            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 The first weird thing to notice about this problem is that
 45d9a15c4b85a2ed89579106bdafd84accf2cb39 is all about LHSes of `RULES`,
 but there ''aren't any'' rules in the test module. So something seems to
 have gone wrong with one of the "knock on" changes.

 Compiling before and after with `-v3` indicates that the simplifier
 iteration immediately after float out takes ''much'' longer, and produces
 somewhat more coercions. That iteration takes many times longer than any
 other. Most of the coercions, before and after, go away after that
 iteration, stabilizing quickly at 19. Surprisingly, `-dverbose-core2core`
 looks exactly the same before and after that commit, suggesting something
 went funny with the size calculations, although I can't see how.

 In HEAD, the number of coercions never goes up above 19. Furthermore, the
 time problem has ''moved''. Now, the long iteration is the very first one
 after desugaring! Ugh. I haven't yet tried to find where the time shift
 took place. But the fact that there ''was'' one makes me suspect that the
 new implementation could have accidentally strictified something it
 shouldn't have. I don't understand what's going on well enough to know
 what. Perhaps the fact that a couple pure functions have turned monadic?

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