#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 Simon Peyton Jones <simonpj@…>): In [changeset:"a1b753e8b1475659440f524b3e66dfbea31c5787/ghc" a1b753e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a1b753e8b1475659440f524b3e66dfbea31c5787" Cure exponential behaviour in the simplifier This patch nails a Bad Bug exposed in Trac #13379. Roughly, a deeply-nested application like f (f (f ....) ) ) could make the simplifier go exponential -- without producing an exponential-sized result! The reason was that we - simplified a (big) function argument - then decided to inline the function - then preInilneUnconditionally the argument - and then re-simplified the big argument And if the "big argument" itself had a similar structure things could get very bad. Once I'd understood, it was easy to fix: * See Note Note [Avoiding exponential behaviour] for an overview * The key change is that Simplify.simplLam now as a case for (isSimplified dup). This is what removes the perf bug. * But I also made simplCast more parsimonious about simplifying, avoiding doing so when the coercion is Refl * And similarly I now try to avoid simplifying arguments where possible before applying rules. See Note [Trying rewrite rules] The latter two points tackle common cases, and in those cases make the simplifier take fewer iterations. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler