Is there any reason not to use the INLINABLE pragma for a function?

Question

The documentation states:

An {-# INLINABLE f #-} pragma on a function f has the following behaviour:

• While INLINE says "please inline me", the INLINABLE says "feel free to inline me; use your discretion". In other words the choice is left to GHC, which uses the same rules as for pragma-free functions. Unlike INLINE, that decision is made at the call site, and will therefore be affected by the inlining threshold, optimisation level etc.

• Like INLINE, the INLINABLE pragma retains a copy of the original RHS for inlining purposes, and persists it in the interface file, regardless of the size of the RHS.

• One way to use INLINABLE is in conjunction with the special function inline (Section 7.18, “Special built-in functions”). The call inline f tries very hard to inline f. To make sure that f can be inlined, it is a good idea to mark the definition of f as INLINABLE, so that GHC guarantees to expose an unfolding regardless of how big it is. Moreover, by annotating f as INLINABLE, you ensure that f's original RHS is inlined, rather than whatever random optimised version of f GHC's optimiser has produced.

• The INLINABLE pragma also works with SPECIALISE: if you mark function f as INLINABLE, then you can subsequently SPECIALISE in another module (see Section 7.16.8, “SPECIALIZE pragma”).

• Unlike INLINE, it is OK to use an INLINABLE pragma on a recursive function. The principal reason do to so to allow later use of SPECIALISE

What's the disadvantage of it?

Does it make interface files much, much bigger? Does it make compilation much slower?

Is there any reason I shouldn't put an INLINABLE pragma on every exported function I write? Is there any reason GHC doesn't put an INLINABLE pragma on every exported function I write?

Answer 1

There are three differences between using INLINABLE and not using a pragma at all:

• Without INLINABLE, the definition that goes in the interface file is the code after optimisation, whereas with INLINABLE, it is the code you wrote (more or less). In particular, without INLINABLE, GHC might inline other functions into the function's definition.

• Without INLINABLE, GHC will omit the definition from the interface file if it is too big. If some other function got inlined into the right-hand-side, this could easily push it over the limit.

• INLINABLE also turns on some clever machinery that automatically specialises overloaded functions where they are used, and shares the specialised versions with other modules that transitively import the module in which the specialised version was created.