[GHC] #14001: Inlining does not work between modules

[GHC]

#14001: Inlining does not work between modules
-------------------------------------+-------------------------------------
        Reporter:  danilo2           |                Owner:  (none)
            Type:  bug               |               Status:  closed
        Priority:  high              |            Milestone:
       Component:  Compiler          |              Version:  8.0.2
      Resolution:  invalid           |             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 danilo2):

 Ok, I've just re-visited this issue and I've got one additional question.
 GHC.Base has definition of `(.)` like the following :

 {{{
 (.) :: (b -> c) -> (a -> b) -> a -> c
 (.) f g = \x -> f (g x) ; {-# INLINE (.) #-}
 }}}

 @simonpj You've told that making own definition of (.) with one of its
 arguments strict, obviously affects the performance (makes the custom (.)
 implementation 40x faster in some use cases). I still consider it to be
 GHC bug even if we can justify it by some internal compiler design.

 If GHC is told to inline the `(.)` definition, why inlining such code into
 strict code doesn't make GHC automatically discover that every parameter
 was already strict there? Why inlining such definition makes strict code
 run slow?

 I'm looking at it from user perspective. For me telling users to have two
 definitions of (.) - one strict and one lazy and using strict one in
 strict code and lazy one in lazy code makes Haskell so hard to understand
 and so hard to use. Thus I believe we should consider this bug and should
 expect from GHC to automatically optimize usages of (.) in strict code. If
 I understand correctly, what happens here is that arguments to (.) are
 boxed (because (.) was defined as lazy) and are unboxed as soon as passed
 to `f` and `g`, because they were defined as strict.

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