[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