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

[GHC]

#14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)
-------------------------------------+-------------------------------------
           Reporter:                 |             Owner:  (none)
  MikolajKonarski                    |
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.2.1
           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:
-------------------------------------+-------------------------------------
 First, let me explain the context. By defuault GHC specialises very few
 functions and the programmer is expected to enumerate additional functions
 to specialise (e.g., with INLINABLE). This is problematic if the functions
 are defined in libraries, not in the user code. Also, in some kinds of
 code it leads to INLINABLE on every functions (because missing even just
 one breaks the chain). The problems are described in other tickets.

 With `-fspecialise-aggressively` and `-fexpose-all-unfoldings`, the
 default is reversed. Everything (even functions from libraries, as long as
 they have unfoldings available) is specialized and the user only needs to
 enumerate exceptions. Unfortunately, he can't.

 I think (in particular from experiments with `-Wall-missed-
 specialisations`), in the presence of `-fexpose-all-unfoldings`, the
 `-fspecialise-aggressively` option happily specialises functions marked
 `NOINLINE` (and so with `Inline:,` in the .hi file). Consequently, the
 user has no way to be selective wrt specialisation when using the
 specialize-often default.

 If we want to gradually disentangle INLINE and SPECIALIZE (e.g., rename
 INLINABLE to SPECIALISABLE), perhaps the pragma to use should be
 NOSPECIALISABLE. Perhaps it also makes sense to leave the current
 functionality, for experimenting with whole modules, but I'd rename it to
 `-fforce-specialise-aggressively`, because it overrides the obvious user
 intent.

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