#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