[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:                 |             Owner:
  MikolajKonarski                    |
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 INLINE vs NOINLE vs <nothing> for this function

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

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

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