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?