[GHC] #12603: INLINE and manually inlining produce different code

[GHC]

#12603: INLINE and manually inlining produce different code
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  bgamari
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       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):

 > When I INLINE the function, I get 3,421,310,504 bytes allocated in the
 heap (runtime 5.32s, but there is much wider measurement error margin that
 with allocation), when I NOINLINE it, I get 2,932,616,792 (5.17s) and when
 I leave it alone (I guess GHC inlines it somehow differently), I get
 4,309,699,560 (5.57s).

 This isn't necessarily surprising.  Consider
 {{{
 module M( f, g, h ) where
   f x = BIG
   g x = (f x, True)
   h x = ...(g x)...
 }}}
 Without an INLINE on `f`, GHC won't inline it (because it's big).  But `g`
 is small, so it'll get inlined into `h`, and good things may happen
 because `h` can see the pair and `True`.

 But if you add an `INLINE` pragma to `f`, then `g` becomes big, so GHC
 won't inline it.

 These effects can be large, and are very hard to predict.  GHC makes no
 guarantees, I'm afraid.

 It's a bit more puzzling that you say your big function is called only
 once; so it might come down to a race as to whether `f` gets auto-inlined
 before `g` does.  That's a bit mysterious I admit.

 However a difference between 2.9G and 4.3G is very large, and it would be
 great to get more insight into why.  I use `-ticky` to investigate this
 kind of thing.

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