Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)

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.

Trac metadata

Trac field	Value
Version	8.2.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture