nativeGen: Allow -fregs-graph to be used
[ghc.git] / docs / users_guide / using-optimisation.rst
1 .. _options-optimise:
2
3 Optimisation (code improvement)
4 -------------------------------
5
6 .. index::
7    single: optimisation
8    single: improvement, code
9
10 The ``-O*`` options specify convenient "packages" of optimisation flags;
11 the ``-f*`` options described later on specify *individual*
12 optimisations to be turned on/off; the ``-m*`` options specify
13 *machine-specific* optimisations to be turned on/off.
14
15 Most of these options are boolean and have options to turn them both "on" and
16 "off" (beginning with the prefix ``no-``). For instance, while ``-fspecialise``
17 enables specialisation, ``-fno-specialise`` disables it. When multiple flags for
18 the same option appear in the command-line they are evaluated from left to
19 right. For instance, ``-fno-specialise -fspecialise`` will enable
20 specialisation.
21
22 It is important to note that the ``-O*`` flags are roughly equivalent to
23 combinations of ``-f*`` flags. For this reason, the effect of the
24 ``-O*`` and ``-f*`` flags is dependent upon the order in which they
25 occur on the command line.
26
27 For instance, take the example of ``-fno-specialise -O1``. Despite the
28 ``-fno-specialise`` appearing in the command line, specialisation will
29 still be enabled. This is the case as ``-O1`` implies ``-fspecialise``,
30 overriding the previous flag. By contrast, ``-O1 -fno-specialise`` will
31 compile without specialisation, as one would expect.
32
33 .. _optimise-pkgs:
34
35 ``-O*``: convenient “packages” of optimisation flags.
36 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
37
38 There are *many* options that affect the quality of code produced by
39 GHC. Most people only have a general goal, something like "Compile
40 quickly" or "Make my program run like greased lightning." The following
41 "packages" of optimisations (or lack thereof) should suffice.
42
43 Note that higher optimisation levels cause more cross-module
44 optimisation to be performed, which can have an impact on how much of
45 your program needs to be recompiled when you change something. This is
46 one reason to stick to no-optimisation when developing code.
47
48 .. ghc-flag:: -O*
49
50     This is taken to mean: “Please compile quickly; I'm not
51     over-bothered about compiled-code quality.” So, for example:
52     ``ghc -c Foo.hs``
53
54 .. ghc-flag:: -O0
55
56     Means "turn off all optimisation", reverting to the same settings as
57     if no ``-O`` options had been specified. Saying ``-O0`` can be
58     useful if e.g. ``make`` has inserted a ``-O`` on the command line
59     already.
60
61 .. ghc-flag:: -O
62               -O1
63
64     .. index::
65        single: optimise; normally
66
67     Means: "Generate good-quality code without taking too long about
68     it." Thus, for example: ``ghc -c -O Main.lhs``
69
70 .. ghc-flag:: -O2
71
72     .. index::
73        single: optimise; aggressively
74
75     Means: "Apply every non-dangerous optimisation, even if it means
76     significantly longer compile times."
77
78     The avoided "dangerous" optimisations are those that can make
79     runtime or space *worse* if you're unlucky. They are normally turned
80     on or off individually.
81
82 .. ghc-flag:: -Odph
83
84     .. index::
85        single: optimise; DPH
86
87     Enables all ``-O2`` optimisation, sets
88     ``-fmax-simplifier-iterations=20`` and ``-fsimplifier-phases=3``.
89     Designed for use with :ref:`Data Parallel Haskell (DPH) <dph>`.
90
91 We don't use a ``-O*`` flag for day-to-day work. We use ``-O`` to get
92 respectable speed; e.g., when we want to measure something. When we want
93 to go for broke, we tend to use ``-O2`` (and we go for lots of coffee
94 breaks).
95
96 The easiest way to see what ``-O`` (etc.) “really mean” is to run with
97 :ghc-flag:`-v`, then stand back in amazement.
98
99 .. _options-f:
100
101 ``-f*``: platform-independent flags
102 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103
104 .. index::
105    single: -f\* options (GHC)
106    single: -fno-\* options (GHC)
107
108 These flags turn on and off individual optimisations. Flags marked as
109 on by default are enabled by ``-O``, and as such you shouldn't
110 need to set any of them explicitly. A flag ``-fwombat`` can be negated
111 by saying ``-fno-wombat``. See :ref:`options-f-compact` for a compact
112 list.
113
114 .. ghc-flag:: -fcase-merge
115
116     :default: on
117
118     Merge immediately-nested case expressions that scrutinse the same variable.
119     For example, ::
120
121           case x of
122              Red -> e1
123              _   -> case x of
124                       Blue -> e2
125                       Green -> e3
126
127     Is transformed to, ::
128
129           case x of
130              Red -> e1
131              Blue -> e2
132              Green -> e2
133
134 .. ghc-flag:: -fcall-arity
135
136     :default: on
137
138     Enable call-arity analysis.
139
140 .. ghc-flag:: -fcmm-elim-common-blocks
141
142     :default: on
143
144     Enables the common block elimination optimisation
145     in the code generator. This optimisation attempts to find identical
146     Cmm blocks and eliminate the duplicates.
147
148 .. ghc-flag:: -fcmm-sink
149
150     :default: on
151
152     Enables the sinking pass in the code generator.
153     This optimisation attempts to find identical Cmm blocks and
154     eliminate the duplicates attempts to move variable bindings closer
155     to their usage sites. It also inlines simple expressions like
156     literals or registers.
157
158 .. ghc-flag:: -fcpr-off
159
160     Switch off CPR analysis in the demand analyser.
161
162 .. ghc-flag:: -fcse
163
164     :default: on
165
166     Enables the common-sub-expression elimination
167     optimisation. Switching this off can be useful if you have some
168     ``unsafePerformIO`` expressions that you don't want commoned-up.
169
170 .. ghc-flag:: -fdicts-cheap
171
172     A very experimental flag that makes dictionary-valued expressions
173     seem cheap to the optimiser.
174
175 .. ghc-flag:: -fdicts-strict
176
177     Make dictionaries strict.
178
179 .. ghc-flag:: -fdmd-tx-dict-sel
180
181     *On by default for ``-O0``, ``-O``, ``-O2``.*
182
183     Use a special demand transformer for dictionary selectors.
184
185 .. ghc-flag:: -fdo-eta-reduction
186
187     :default: on
188
189     Eta-reduce lambda expressions, if doing so gets rid of a whole group of
190     lambdas.
191
192 .. ghc-flag:: -fdo-lambda-eta-expansion
193
194     :default: on
195
196     Eta-expand let-bindings to increase their arity.
197
198 .. ghc-flag:: -feager-blackholing
199
200     Usually GHC black-holes a thunk only when it switches threads. This
201     flag makes it do so as soon as the thunk is entered. See `Haskell on
202     a shared-memory
203     multiprocessor <http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/>`__.
204
205 .. ghc-flag:: -fexcess-precision
206
207     When this option is given, intermediate floating point values can
208     have a *greater* precision/range than the final type. Generally this
209     is a good thing, but some programs may rely on the exact
210     precision/range of ``Float``/``Double`` values and should not use
211     this option for their compilation.
212
213     Note that the 32-bit x86 native code generator only supports
214     excess-precision mode, so neither ``-fexcess-precision`` nor
215     ``-fno-excess-precision`` has any effect. This is a known bug, see
216     :ref:`bugs-ghc`.
217
218 .. ghc-flag:: -fexpose-all-unfoldings
219
220     An experimental flag to expose all unfoldings, even for very large
221     or recursive functions. This allows for all functions to be inlined
222     while usually GHC would avoid inlining larger functions.
223
224 .. ghc-flag:: -ffloat-in
225
226     :default: on
227
228     Float let-bindings inwards, nearer their binding
229     site. See `Let-floating: moving bindings to give faster programs
230     (ICFP'96) <http://research.microsoft.com/en-us/um/people/simonpj/papers/float.ps.gz>`__.
231
232     This optimisation moves let bindings closer to their use site. The
233     benefit here is that this may avoid unnecessary allocation if the
234     branch the let is now on is never executed. It also enables other
235     optimisation passes to work more effectively as they have more
236     information locally.
237
238     This optimisation isn't always beneficial though (so GHC applies
239     some heuristics to decide when to apply it). The details get
240     complicated but a simple example is that it is often beneficial to
241     move let bindings outwards so that multiple let bindings can be
242     grouped into a larger single let binding, effectively batching their
243     allocation and helping the garbage collector and allocator.
244
245 .. ghc-flag:: -ffull-laziness
246
247     :default: on
248
249     Run the full laziness optimisation (also known as
250     let-floating), which floats let-bindings outside enclosing lambdas,
251     in the hope they will be thereby be computed less often. See
252     `Let-floating: moving bindings to give faster programs
253     (ICFP'96) <http://research.microsoft.com/en-us/um/people/simonpj/papers/float.ps.gz>`__.
254     Full laziness increases sharing, which can lead to increased memory
255     residency.
256
257     .. note::
258        GHC doesn't implement complete full-laziness. When
259        optimisation in on, and ``-fno-full-laziness`` is not given, some
260        transformations that increase sharing are performed, such as
261        extracting repeated computations from a loop. These are the same
262        transformations that a fully lazy implementation would do, the
263        difference is that GHC doesn't consistently apply full-laziness, so
264        don't rely on it.
265
266 .. ghc-flag:: -ffun-to-thunk
267
268     :default: off
269
270     Worker-wrapper removes unused arguments, but usually we do not
271     remove them all, lest it turn a function closure into a thunk,
272     thereby perhaps creating a space leak and/or disrupting inlining.
273     This flag allows worker/wrapper to remove *all* value lambdas.
274
275 .. ghc-flag:: -fignore-asserts
276
277     :default: on
278
279     Causes GHC to ignore uses of the function ``Exception.assert`` in source
280     code (in other words, rewriting ``Exception.assert p e`` to ``e`` (see
281     :ref:`assertions`).
282
283 .. ghc-flag:: -fignore-interface-pragmas
284
285     Tells GHC to ignore all inessential information when reading
286     interface files. That is, even if :file:`M.hi` contains unfolding or
287     strictness information for a function, GHC will ignore that
288     information.
289
290 .. ghc-flag:: -flate-dmd-anal
291
292     Run demand analysis again, at the end of the simplification
293     pipeline. We found some opportunities for discovering strictness
294     that were not visible earlier; and optimisations like
295     :ghc-flag:`-fspec-constr` can create functions with unused arguments which
296     are eliminated by late demand analysis. Improvements are modest, but
297     so is the cost. See notes on the :ghc-wiki:`Trac wiki page <LateDmd>`.
298
299 .. ghc-flag:: -fliberate-case
300
301     *Off by default, but enabled by -O2.* Turn on the liberate-case
302     transformation. This unrolls recursive function once in its own RHS,
303     to avoid repeated case analysis of free variables. It's a bit like
304     the call-pattern specialiser (:ghc-flag:`-fspec-constr`) but for free
305     variables rather than arguments.
306
307 .. ghc-flag:: -fliberate-case-threshold=<n>
308
309     :default: 2000
310
311     Set the size threshold for the liberate-case transformation.
312
313 .. ghc-flag:: -floopification
314
315     :default: on
316
317     When this optimisation is enabled the code generator will turn all
318     self-recursive saturated tail calls into local jumps rather than
319     function calls.
320
321 .. ghc-flag:: -fmax-inline-alloc-size=<n>
322
323     :default: 128
324
325     Set the maximum size of inline array allocations to n bytes.
326     GHC will allocate non-pinned arrays of statically known size in the current
327     nursery block if they're no bigger than n bytes, ignoring GC overheap. This
328     value should be quite a bit smaller than the block size (typically: 4096).
329
330 .. ghc-flag:: -fmax-inline-memcpy-insn=<n>
331
332     :default: 32
333
334     Inline ``memcpy`` calls if they would generate no more than ⟨n⟩ pseudo-instructions.
335
336 .. ghc-flag:: -fmax-inline-memset-insns=<n>
337
338     :default: 32
339
340     Inline ``memset`` calls if they would generate no more than n pseudo
341     instructions.
342
343 .. ghc-flag:: -fmax-relevant-binds=<n>
344               -fno-max-relevant-bindings
345
346     :default: 6
347
348     The type checker sometimes displays a fragment of the type
349     environment in error messages, but only up to some maximum number,
350     set by this flag. Turning it off with
351     ``-fno-max-relevant-bindings`` gives an unlimited number.
352     Syntactically top-level bindings are also usually excluded (since
353     they may be numerous), but ``-fno-max-relevant-bindings`` includes
354     them too.
355
356 .. ghc-flag:: -fmax-uncovered-patterns=<n>
357
358     :default: 4
359
360     Maximum number of unmatched patterns to be shown in warnings generated by
361     :ghc-flag:`-Wincomplete-patterns` and :ghc-flag:`-Wincomplete-uni-patterns`.
362
363 .. ghc-flag:: -fmax-simplifier-iterations=<n>
364
365     :default: 4
366
367     Sets the maximal number of iterations for the simplifier.
368
369 .. ghc-flag:: -fmax-worker-args=<n>
370
371     :default: 10
372
373     If a worker has that many arguments, none will be unpacked anymore.
374
375 .. ghc-flag:: -fno-opt-coercion
376
377     Turn off the coercion optimiser.
378
379 .. ghc-flag:: -fno-pre-inlining
380
381     Turn off pre-inlining.
382
383 .. ghc-flag:: -fno-state-hack
384
385     Turn off the "state hack" whereby any lambda with a ``State#`` token
386     as argument is considered to be single-entry, hence it is considered
387     okay to inline things inside it. This can improve performance of IO
388     and ST monad code, but it runs the risk of reducing sharing.
389
390 .. ghc-flag:: -fomit-interface-pragmas
391
392     Tells GHC to omit all inessential information from the interface
393     file generated for the module being compiled (say M). This means
394     that a module importing M will see only the *types* of the functions
395     that M exports, but not their unfoldings, strictness info, etc.
396     Hence, for example, no function exported by M will be inlined into
397     an importing module. The benefit is that modules that import M will
398     need to be recompiled less often (only when M's exports change their
399     type, not when they change their implementation).
400
401 .. ghc-flag:: -fomit-yields
402
403     :default: on
404
405     Tells GHC to omit heap checks when no allocation is
406     being performed. While this improves binary sizes by about 5%, it
407     also means that threads run in tight non-allocating loops will not
408     get preempted in a timely fashion. If it is important to always be
409     able to interrupt such threads, you should turn this optimization
410     off. Consider also recompiling all libraries with this optimization
411     turned off, if you need to guarantee interruptibility.
412
413 .. ghc-flag:: -fpedantic-bottoms
414
415     Make GHC be more precise about its treatment of bottom (but see also
416     :ghc-flag:`-fno-state-hack`). In particular, stop GHC eta-expanding through
417     a case expression, which is good for performance, but bad if you are
418     using ``seq`` on partial applications.
419
420 .. ghc-flag:: -fregs-graph
421
422     :default: off due to a performance regression bug (:ghc-ticket:`7679`)
423
424     *Only applies in combination with the native code generator.* Use the graph
425     colouring register allocator for register allocation in the native code
426     generator. By default, GHC uses a simpler, faster linear register allocator.
427     The downside being that the linear register allocator usually generates
428     worse code.
429
430     Note that the graph colouring allocator is a bit experimental and may fail
431     when faced with code with high register pressure :ghc-ticket:`8657`.
432
433 .. ghc-flag:: -fregs-iterative
434
435     :default: off
436
437     *Only applies in combination with the native code generator.* Use the
438     iterative coalescing graph colouring register allocator for register
439     allocation in the native code generator. This is the same register allocator
440     as the :ghc-flag:`-fregs-graph` one but also enables iterative coalescing
441     during register allocation.
442
443 .. ghc-flag:: -fsimplifier-phases=<n>
444
445     :default: 2
446
447     Set the number of phases for the simplifier. Ignored with ``-O0``.
448
449 .. ghc-flag:: -fsimpl-tick-factor=<n>
450
451     :default: 100
452
453     GHC's optimiser can diverge if you write rewrite rules
454     (:ref:`rewrite-rules`) that don't terminate, or (less satisfactorily)
455     if you code up recursion through data types (:ref:`bugs-ghc`). To
456     avoid making the compiler fall into an infinite loop, the optimiser
457     carries a "tick count" and stops inlining and applying rewrite rules
458     when this count is exceeded. The limit is set as a multiple of the
459     program size, so bigger programs get more ticks. The
460     ``-fsimpl-tick-factor`` flag lets you change the multiplier. The
461     default is 100; numbers larger than 100 give more ticks, and numbers
462     smaller than 100 give fewer.
463
464     If the tick-count expires, GHC summarises what simplifier steps it
465     has done; you can use ``-fddump-simpl-stats`` to generate a much
466     more detailed list. Usually that identifies the loop quite
467     accurately, because some numbers are very large.
468
469 .. ghc-flag:: -fspec-constr
470
471     *Off by default, but enabled by -O2.* Turn on call-pattern
472     specialisation; see `Call-pattern specialisation for Haskell
473     programs <http://research.microsoft.com/en-us/um/people/simonpj/papers/spec-constr/index.htm>`__.
474
475     This optimisation specializes recursive functions according to their
476     argument "shapes". This is best explained by example so consider: ::
477
478         last :: [a] -> a
479         last [] = error "last"
480         last (x : []) = x
481         last (x : xs) = last xs
482
483     In this code, once we pass the initial check for an empty list we
484     know that in the recursive case this pattern match is redundant. As
485     such ``-fspec-constr`` will transform the above code to: ::
486
487         last :: [a] -> a
488         last []       = error "last"
489         last (x : xs) = last' x xs
490             where
491               last' x []       = x
492               last' x (y : ys) = last' y ys
493
494     As well avoid unnecessary pattern matching it also helps avoid
495     unnecessary allocation. This applies when a argument is strict in
496     the recursive call to itself but not on the initial entry. As strict
497     recursive branch of the function is created similar to the above
498     example.
499
500     It is also possible for library writers to instruct GHC to perform
501     call-pattern specialisation extremely aggressively. This is
502     necessary for some highly optimized libraries, where we may want to
503     specialize regardless of the number of specialisations, or the size
504     of the code. As an example, consider a simplified use-case from the
505     ``vector`` library: ::
506
507         import GHC.Types (SPEC(..))
508
509         foldl :: (a -> b -> a) -> a -> Stream b -> a
510         {-# INLINE foldl #-}
511         foldl f z (Stream step s _) = foldl_loop SPEC z s
512           where
513             foldl_loop !sPEC z s = case step s of
514                                     Yield x s' -> foldl_loop sPEC (f z x) s'
515                                     Skip       -> foldl_loop sPEC z s'
516                                     Done       -> z
517
518     Here, after GHC inlines the body of ``foldl`` to a call site, it
519     will perform call-pattern specialisation very aggressively on
520     ``foldl_loop`` due to the use of ``SPEC`` in the argument of the
521     loop body. ``SPEC`` from ``GHC.Types`` is specifically recognised by
522     the compiler.
523
524     (NB: it is extremely important you use ``seq`` or a bang pattern on
525     the ``SPEC`` argument!)
526
527     In particular, after inlining this will expose ``f`` to the loop
528     body directly, allowing heavy specialisation over the recursive
529     cases.
530
531 .. ghc-flag:: -fspec-constr-count=<n>
532
533     :default: 3
534
535     Set the maximum number of specialisations that will be created for
536     any one function by the SpecConstr transformation.
537
538 .. ghc-flag:: -fspec-constr-threshold=<n>
539
540     :default: 2000
541
542     Set the size threshold for the SpecConstr transformation.
543
544 .. ghc-flag:: -fspecialise
545
546     :default: on
547
548     Specialise each type-class-overloaded function
549     defined in this module for the types at which it is called in this
550     module. If :ghc-flag:`-fcross-module-specialise` is set imported functions
551     that have an INLINABLE pragma (:ref:`inlinable-pragma`) will be
552     specialised as well.
553
554 .. ghc-flag:: -fcross-module-specialise
555
556     :default: on
557
558     Specialise ``INLINABLE`` (:ref:`inlinable-pragma`)
559     type-class-overloaded functions imported from other modules for the types at
560     which they are called in this module. Note that specialisation must be
561     enabled (by ``-fspecialise``) for this to have any effect.
562
563 .. ghc-flag:: -fstatic-argument-transformation
564
565     Turn on the static argument transformation, which turns a recursive
566     function into a non-recursive one with a local recursive loop. See
567     Chapter 7 of `Andre Santos's PhD
568     thesis <http://research.microsoft.com/en-us/um/people/simonpj/papers/santos-thesis.ps.gz>`__
569
570 .. ghc-flag:: -fstrictness
571
572     :default: on
573
574     Switch on the strictness analyser. There is a very
575     old paper about GHC's strictness analyser, `Measuring the
576     effectiveness of a simple strictness
577     analyser <http://research.microsoft.com/en-us/um/people/simonpj/papers/simple-strictnes-analyser.ps.gz>`__,
578     but the current one is quite a bit different.
579
580     The strictness analyser figures out when arguments and variables in
581     a function can be treated 'strictly' (that is they are always
582     evaluated in the function at some point). This allow GHC to apply
583     certain optimisations such as unboxing that otherwise don't apply as
584     they change the semantics of the program when applied to lazy
585     arguments.
586
587 .. ghc-flag:: -fstrictness-before=⟨n⟩
588
589     Run an additional strictness analysis before simplifier phase ⟨n⟩.
590
591 .. ghc-flag:: -funbox-small-strict-fields
592
593     :default: on
594
595     .. index::
596        single: strict constructor fields
597        single: constructor fields, strict
598
599     This option causes all constructor fields which
600     are marked strict (i.e. “!”) and which representation is smaller or
601     equal to the size of a pointer to be unpacked, if possible. It is
602     equivalent to adding an ``UNPACK`` pragma (see :ref:`unpack-pragma`)
603     to every strict constructor field that fulfils the size restriction.
604
605     For example, the constructor fields in the following data types ::
606
607         data A = A !Int
608         data B = B !A
609         newtype C = C B
610         data D = D !C
611
612     would all be represented by a single ``Int#`` (see
613     :ref:`primitives`) value with ``-funbox-small-strict-fields``
614     enabled.
615
616     This option is less of a sledgehammer than
617     ``-funbox-strict-fields``: it should rarely make things worse. If
618     you use ``-funbox-small-strict-fields`` to turn on unboxing by
619     default you can disable it for certain constructor fields using the
620     ``NOUNPACK`` pragma (see :ref:`nounpack-pragma`).
621
622     Note that for consistency ``Double``, ``Word64``, and ``Int64``
623     constructor fields are unpacked on 32-bit platforms, even though
624     they are technically larger than a pointer on those platforms.
625
626 .. ghc-flag:: -funbox-strict-fields
627
628     .. index::
629        single: strict constructor fields
630        single: constructor fields, strict
631
632     This option causes all constructor fields which are marked strict
633     (i.e. ``!``) to be unpacked if possible. It is equivalent to adding an
634     ``UNPACK`` pragma to every strict constructor field (see
635     :ref:`unpack-pragma`).
636
637     This option is a bit of a sledgehammer: it might sometimes make
638     things worse. Selectively unboxing fields by using ``UNPACK``
639     pragmas might be better. An alternative is to use
640     ``-funbox-strict-fields`` to turn on unboxing by default but disable
641     it for certain constructor fields using the ``NOUNPACK`` pragma (see
642     :ref:`nounpack-pragma`).
643
644 .. ghc-flag:: -funfolding-creation-threshold=<n>
645
646     :default: 750
647
648     .. index::
649        single: inlining, controlling
650        single: unfolding, controlling
651
652     Governs the maximum size that GHC will allow a
653     function unfolding to be. (An unfolding has a “size” that reflects
654     the cost in terms of “code bloat” of expanding (aka inlining) that
655     unfolding at a call site. A bigger function would be assigned a
656     bigger cost.)
657
658     Consequences:
659
660     a. nothing larger than this will be inlined (unless it has an ``INLINE`` pragma)
661     b. nothing larger than this will be spewed into an interface file.
662
663     Increasing this figure is more likely to result in longer compile
664     times than faster code. The :ghc-flag:`-funfolding-use-threshold` is more
665     useful.
666
667 .. ghc-flag:: -funfolding-dict-discount=<n>
668
669     :default: 30
670
671     .. index::
672        single: inlining, controlling
673        single: unfolding, controlling
674
675     How eager should the compiler be to inline dictionaries?
676
677 .. ghc-flag:: -funfolding-fun-discount=<n>
678
679     :default: 60
680
681     .. index::
682        single: inlining, controlling
683        single: unfolding, controlling
684
685     How eager should the compiler be to inline functions?
686
687 .. ghc-flag:: -funfolding-keeness-factor=<n>
688
689     :default: 1.5
690
691     .. index::
692        single: inlining, controlling
693        single: unfolding, controlling
694
695     How eager should the compiler be to inline functions?
696
697 .. ghc-flag:: -funfolding-use-threshold=<n>
698
699     :default: 60
700
701     .. index::
702        single: inlining, controlling
703        single: unfolding, controlling
704
705     This is the magic cut-off figure for unfolding (aka
706     inlining): below this size, a function definition will be unfolded
707     at the call-site, any bigger and it won't. The size computed for a
708     function depends on two things: the actual size of the expression
709     minus any discounts that apply depending on the context into which
710     the expression is to be inlined.
711
712     The difference between this and :ghc-flag:`-funfolding-creation-threshold`
713     is that this one determines if a function definition will be inlined
714     *at a call site*. The other option determines if a function
715     definition will be kept around at all for potential inlining.
716
717 .. ghc-flag:: -fvectorisation-avoidance
718
719     :default: on
720
721     .. index::
722        single: -fvectorisation-avoidance
723
724     Part of :ref:`Data Parallel Haskell (DPH) <dph>`.
725
726     Enable the *vectorisation* avoidance optimisation.
727     This optimisation only works when used in combination with the
728     ``-fvectorise`` transformation.
729
730     While vectorisation of code using DPH is often a big win, it can
731     also produce worse results for some kinds of code. This optimisation
732     modifies the vectorisation transformation to try to determine if a
733     function would be better of unvectorised and if so, do just that.
734
735 .. ghc-flag:: -fvectorise
736
737     :default: off
738
739     Part of :ref:`Data Parallel Haskell (DPH) <dph>`.
740
741     Enable the *vectorisation* optimisation
742     transformation. This optimisation transforms the nested data
743     parallelism code of programs using DPH into flat data parallelism.
744     Flat data parallel programs should have better load balancing,
745     enable SIMD parallelism and friendlier cache behaviour.