#13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's my work-in-progress {{{ Modified compiler/simplCore/SimplUtils.hs diff --git a/compiler/simplCore/SimplUtils.hs b/compiler/simplCore/SimplUtils.hs index 7deaf5b..2f9e2e9 100644 --- a/compiler/simplCore/SimplUtils.hs +++ b/compiler/simplCore/SimplUtils.hs @@ -1200,7 +1200,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. - && (not in_lam || + && ( (not in_lam && not (isValueUnfolding unfolding)) || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> @@ -1209,7 +1209,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' - (isCheapUnfolding unfolding && int_cxt)) + (int_cxt && isCheapUnfolding unfolding)) -- isCheap => acceptable work duplication; in_lam may be true -- int_cxt to prevent us inlining inside a lambda without some -- good reason. See the notes on int_cxt in preInlineUnconditionally }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13316#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler