[GHC] #7511: Room for GHC runtime improvement >~5%, inlining related

[GHC]

#7511: Room for GHC runtime improvement >~5%, inlining related
------------------------------------+---------------------------------------
Reporter:  danielv                  |          Owner:                  
    Type:  bug                      |         Status:  new             
Priority:  normal                   |      Component:  Compiler        
 Version:  7.6.1                    |       Keywords:                  
      Os:  Unknown/Multiple         |   Architecture:  Unknown/Multiple
 Failure:  Runtime performance bug  |      Blockedby:                  
Blocking:                           |        Related:                  
------------------------------------+---------------------------------------

Comment(by nfrisby):

 Just FYI, I've recently seen one example where more inlining caused an
 increase in allocation. Here's an abstraction:

 {{{
 f a b = let-no-escape j = ...
         in ... j ...

 g x y = ... case f (...) (...) of ...
 }}}

 f got inlined and the j binding got floated out a bit. Thus j was no
 longer LNE, since the result of its call was scrutinized.

 This happened in puzzle; the StateType's == and /= methods were f and g,
 respectively. I had accidentally awarded a huge result discount to ==.
 Yell if you'd like more details.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7511#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler