[GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)

[GHC]

#14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)
-------------------------------------+-------------------------------------
        Reporter:  MikolajKonarski   |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by MikolajKonarski):

 I think there are many way to interpret the negative flags. I can easily
 think about two: by trigger (passes) and by mechanism (micro-decisions).
 Let me explain by sketching the semantics of NOSPECIALISABLE pragma. For
 simplicity I assume GHC works by making separate passes over code, e.g.,
 inlining pass and specialising pass. I think this is a good mental model
 for a programmer, as opposed to a tangled mess of iterated optimization
 micro-decisions, even if the latter is much closer to reality.

 NOSPECIALISABLE by trigger: when GHC is looking for functions to
 specialise, ignore the function. The inlining pass may independently
 decide to inline it.

 NOSPECIALISABLE by mechanism: in the specialisation pass, if the function
 meets the criteria for specialisation *and* specialisation-by-inlining,
 inline it, otherwise ignore it, never create a specialised copy. The
 inlining pass is free to make its own decisions, in particular, criteria
 for inlining may be different than for specialisation-by-inlining.

 For my use case, for simplicity of the mental model, I'd prefer by-trigger
 semantics, because I want the NOSPECIALISABLE to just mark an exception to
 the `-fspecialise-aggressively` option and I understand such global
 default-changing options to affect passes --- decisions whether a
 functions should be transformed at all, not micro-decisions how to best
 transform it (e.g., whether to specialize it by copy or by inlining). If
 one wants to risk forcing particular micro-decisions, there are other GHC
 flags to use, e.g., the thresholds for inlining and other fine-tuning, but
 the results are hard to predict and context-sensitive, so I'd keep them
 separate.

 Examples of the by-trigger semantics, SPECIALISABLE+NOINLINE is free to
 perform specialisation-by-inlining, because NOINLINE just says to ignore
 the function during the inlining pass (but not during the specialising
 pass). INLINE+NOSPECIALISABLE is not equivalent to INLINE, I guess,
 because a recursive function can't be inlined, but might be specialized by
 copy.

 The by-trigger semantics probably doesn't match the reality of GHC code
 and the current semantics of NOINLINE. For the trigger semantics there
 would need to be separate code that checks whether a function should be
 considered for inlining and a separate code that checks if a function we
 are specializing should instead be inlined. The NOINLINE pragma would only
 be inspected in the former. This also implies NOINLINE should not inhibit
 exposing of unfoldings.

 The by-trigger semantics in full:

 * NOINLINE: please do not consider this function when deciding which
 functions to inline (even if it fits the criteria). But GHC is free to
 specialise it, even inlining it in the process.
 * NOSPECIALISABLE: please do not specialise this function (even if it
 would otherwise be easy to do so).

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