[GHC] #12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better

[GHC]

#12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be
better
-------------------------------------+-------------------------------------
        Reporter:  MikolajKonarski   |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       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:  #12603 #12781     |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by MikolajKonarski:

@@ -31,1 +31,2 @@
- <nothing> each produce different "MUT time".]
+ <nothing> each produce different "MUT time" in the place marked with "and
+ NOINLINE lands in between".]

New description:

 INLINE vs NOINLE vs <nothing> for this function

 https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145

 produces distinct heap memory allocation figures in all three cases, see

 https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7

 and some later comments, but I'd like to move here the discussion of the
 specific feature request that <nothing> should at any given point be
 equivalent to either INLINE or NOINLINE.

 Three different results are very unwieldy while optimizing code, because
 one cannot tweak the INLINE pragma for functions in isolation, via fixing
 INLINE or NOINLINE for all other functions and varying only one, because
 the optimal setting for some functions may be <nothing>, and it naturally
 varies (as it should; that is fine; but in each particular
 codebase/compilation flags state it should be equal to either of INLINE or
 NOINLINE).

 It seems almost as if GHC considers a function for inlining in some
 stages, optimizes accordingly, but changes its mind in other places, not
 being bound by either INLINE nor NOINLINE, and so the resulting stack of
 optimizations is different than in either case. IMHO that's too complex
 behaviour for the programmer to follow, it should irreversibly decide
 whether to inline at exactly the same place it first takes into account
 the NO/INLINE pragmas, if present.

 [Edit: another example is the code in description of ticket
 https://ghc.haskell.org/trac/ghc/ticket/12603, where INLINE, NOINLINE and
 <nothing> each produce different "MUT time" in the place marked with "and
 NOINLINE lands in between".]

--

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