[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 MikolajKonarski):

 Replying to [comment:8 simonpj]:
 > > When I INLINE[...], when I NOINLINE it [...] and when I leave it alone
 [...
 >
 > This isn't necessarily surprising.  Consider [...]

 Thank you for the example. I've fixed the inlining status of all enclosing
 or competing functions in the module, but the strange behaviour persists.
 Now I suspect the complaints I have may not be related after all: 1. not
 floating out constants with INLINE as opposed to identical manual
 inlining; 2. erratic/unpredictable/surprising/buggy behaviour of INLINE vs
 NOINLINE vs <nothing> 3. three different figures for these, instead of
 two.

 I've just opened a feature request ticket for 3:
 https://ghc.haskell.org/trac/ghc/ticket/12747#ticket. This comment is
 about 2. If I find a smaller or simpler example for 2 and it's still as
 surprising, I will open a new bug report for it. As you point out, it's
 possible that 2 is not a bug, but just an exemplification of GHC being
 smarter than either us.

 > 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.

 The guarantee that would help greatly would be that the behaviour of the
 program with neither INLINE nor NOINLINE for function `f` is the same as
 the behaviour with INLINE or that with NOINLINE. It would help
 tremendously with profiling experiments, because then I could fix the
 state of inlining of `f` and tune `g` and `h` without worry that inlining
 of `f` changes silently. But if `f` has the lowest allocation only without
 any pragmas at all, I can't fix it. See the feature request.

 > It's a bit more puzzling that you say your big function is called only
 once

 I meant syntactically (even taking into account inlining of any other
 functions). But it's called inside a loop. It's referenced exactly once
 and fully applied, here:
 https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client/UI/DrawM.hs#L273

 > 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.

 Thank you for the tips.

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