Refactor INLINE pragmas
@AndreasK and I would like to refactor the way in which INLINE pragmas are represented in GHC: see !9621.
A driving motivation is to allow the combination of
-
NOINLINE
(orNOILINE[2]
), to allow rules to fire -
INLINEABLE
, to allow specialisation
There are a number of tickets about this point:
A design I like is this:
Note [Pragmas for an Id]
~~~~~~~~~~~~~~~~~~~~~~~~
An Id can have three, orthogonal, user-specified pragmas, all packed into `PragInfo`
* `INLINE [n]`, `NOINLINE [n]`, `OPAQUE` (mutually exclusive): controls inlining. Fields
* `inl_inline :: InlineSpec`.
* `inl_act :: Activation`: which phase inlining is active.
* `inl_sat :: Maybe Arity`. Only relevant for `INLINE`
* `INLINE` implies `INLINEABLE`; that is, it captures the original RHS of the binding, and sets `inl_stable`=`True`.
* `INLINEABLE`: makes GHC capture the original RHS of the binding, for use in possible specialisations;
also, if GHC decides to inline the function, it'll inline this original RHS. Fields:
* `inl_stable` :: Bool
* No phase on `INLINEABLE`.
* `CONLIKE`: treat applications of this Id as "expandable" like a data constructor. See `Note [ ... ]`. Fields:
* `inl_rule :: RuleMatchInfo`