[GHC] #4960: Better inlining test in CoreUnfold
GHC
cvs-ghc at haskell.org
Tue Feb 15 14:15:36 CET 2011
#4960: Better inlining test in CoreUnfold
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Consider this
{{{
f x = let
$j y = case x of { True -> e1; False -> e2 }
in
case x of
True -> ...$j y1...
False -> ...$j y2...
}}}
If a function that scrutinises its argument is applied to a constructor,
it becomes much keener to inline. But in this example the function
scrutinises a ''free variable'' that is evaluated to a known constructor
at the call site. At the moment this is ignored, and `$j` may well not be
inlined in situations where it would be jolly good to do so.
This shows up in test `perf/should_run/MethSharing` where the join points
created early only inline because `exprIsDupable` is ''just'' generous
enough to do so. If you reduce `CoreUtils.dupAppSize` by 1, the join
point doesn't inline any more. But it should.
The solution is fairly easy: compute discounts on free varaibles as well
as arguments. I'm making a ticket because I don't want to execute on this
today.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4960>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list