#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:"29d88ee173bc9b04245a33d5268dda032f5dc331/ghc" 29d88ee1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29d88ee173bc9b04245a33d5268dda032f5dc331" Be a bit more eager to inline in a strict context If we see f (g x), and f is strict, we want to be a bit more eager to inline g, because it may well expose an eval (on x perhaps) that can be eliminated or shared. I saw this in nofib boyer2, function RewriteFuns.onewayunify1. It showed up as a consequence of the preceding patch that makes the simplifier do less work (Trac #13379). We had f d (g x) where f was a class-op. Previously we simplified both d and (g x) with a RuleArgCtxt (making g a bit more eager to inline). But now we simplify only d that way, then fire the rule, and only then simplify (g x). Firing the rule produces a strict funciion, so we want to make a strict function encourage inlining a bit. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler