[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:                    |
-------------------------------------+-------------------------------------

Comment (by MikolajKonarski):

 Actually, I now see INLINABLE is named similarly to INLINE only by
 coincidence and also by coincidence it's used (though it's much more
 powerful for that) together with inline as a per-call-side analogue of
 INLINE.

 I think what we need is more generally giving a precise and symmetric and
 orthogonal semantics to the optimization-related pragmas (including adding
 many more). If somebody writes a proper GHC proposal for that, please
 close this ticket and let's have the discussion there.

 I also hereby drop the feature request that the behaviour X of GHC in the
 absence of the pragma controlling X for a particular piece of code should
 be equivalent to the source code with pragma X or it's negation. I see GHC
 may control X in a much more fine-grained way than source code
 manipulation permits (e.g., at the level of Core), so it's OK (even if not
 ideal) if GHC produces something smarter than the programmer can possibly
 express.

 However, I still think major GHC optimizations should possess informal
 semantics in terms of source code manipulation and should be controllable
 via a complete set of pragmas that on the level of granularity available
 to the programmer produce exactly the same results as said source code
 manipulations. I think we need per-call-site, per-expression (where
 applicable), per-definition, recursive-per-definition (where applicable),
 per-module and per-project versions of local (only within the module) and
 global (everywhere) versions of positive and negative versions of INLINE,
 KEEP_UNFOLDING_IN_HI_FILE, SPECIALIZABLE (a part of what is currently
 INLINABLE), FLOAT_OUT and a few more pragmas for GHC optimizations that
 have or can be made to have the key property that they have a clear,
 simple semantics in terms of original source code transformation.

 Granted, a few of these combinations don't make sense, e.g., per-module
 and especially per-project INLINE. If GHC can do much smarter things for a
 chunk of program than what the simple source-manipulation semantics
 implies (e.g., by looking at other, distant bits of code or measuring
 sizes and complexity of Core resulting from subexpressions), let's keep
 the smart version to be used when neither pragma X nor it's negation is
 specified, or when some special pragma X_HIPER is given and let's
 nevertheless have pragma X do the simple, naive thing. I see this goes in
 the direction of meta-programming, but to the extent that GHC in fact does
 it, we should embrace meta-programming instead of hiding it. The fact that
 the meta-programming preserves semantics (and only changes performance),
 doesn't make it any less in need of proper, civilized support. Also note
 that while we want GHC to be as smart behind the scenes as possible in the
 final program, we want it to behave in explicit and simple way when we
 juggle pragmas while optimizing by experimentation or while debugging GHC
 itself.

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