add INLINEABLE to maybe, either, bool
Bardur Arantsson
spam at scientician.net
Thu Sep 26 18:02:57 CEST 2013
On 2013-09-26 17:45, Simon Marlow wrote:
> I read this discussion and thought that one small thing we could do is
> to clarify the documentation for INLINE a bit. Here's what I came up
> with; comments welcome. I'll commit this if there are no objections.
>
> <para>
> GHC (with <option>-O</option>, as always) tries to inline
> (or “unfold”) functions/values that are
> “small enough,” thus avoiding the call overhead
> and possibly exposing other more-wonderful optimisations.
> GHC has a set of heuristics, tuned over a long period of
> time using many benchmarks, that decide when it is
> beneficial to inline a function at its call site. The
> heuristics are designed to inline functions when it appears
> to be beneficial to do so, but without incurring excessive
> code bloat. If a function looks too big, it won't be
> inlined, and functions larger than a certain size will not
> even have their definition exported in the interface file.
> Some of the thresholds that govern these heuristic decisions
> can be changed using flags, see <xref linkend="options-f"
> />.
> </para>
>
> <para>
> Normally GHC will do a reasonable job of deciding by itself
> when it is a good idea to inline a function. However,
> sometimes you might want to override the default behaviour.
> For exmaple, if you have a key function that is important to
^^^^^^^
Typo.
More information about the Libraries
mailing list