This is taken to mean: “Please compile quickly; I'm not over-bothered about compiled-code quality.” So, for example: ghc -c Foo.hs

Means “turn off all optimisation”, reverting to the same settings as if no -O options had been specified. Saying -O0 can be useful if eg. make has inserted a -O on the command line already.

Means: “Generate good-quality code without taking too long about it.” Thus, for example: ghc -c -O Main.lhs

Means: “Apply every non-dangerous optimisation, even if it means significantly longer compile times.”

The avoided “dangerous” optimisations are those that can make runtime or space worse if you're unlucky. They are normally turned on or off individually.

At the moment, -O2 is unlikely to produce better code than -O.

When this option is given, intermediate floating point values can have a greater precision/range than the final type. Generally this is a good thing, but some programs may rely on the exact precision/range of Float/Double values and should not use this option for their compilation.

Causes GHC to ignore uses of the function Exception.assert in source code (in other words, rewriting Exception.assert p e to e (see Section 7.15, “Assertions ”). This flag is turned on by -O.

Tells GHC to ignore all inessential information when reading interface files. That is, even if M.hi contains unfolding or strictness information for a function, GHC will ignore that information.

Turn on the liberate-case transformation.

Turns off the common-sub-expression elimination optimisation. Can be useful if you have some unsafePerformIO expressions that you don't want commoned-up.

Turns off the strictness analyser; sometimes it eats too many cycles.

Turns off the full laziness optimisation (also known as let-floating). Full laziness increases sharing, which can lead to increased memory residency.

NOTE: GHC doesn't implement complete full-laziness. When optimisation in on, and -fno-full-laziness is not given, some transformations that increase sharing are performed, such as extracting repeated computations from a loop. These are the same transformations that a fully lazy implementation would do, the difference is that GHC doesn't consistently apply full-laziness, so don't rely on it.

Turns off the float-in transformation.

Turns off the automatic specialisation of overloaded functions.

Turn off the "state hack" whereby any lambda with a State# token as argument is considered to be single-entry, hence it is considered OK to inline things inside it. This can improve performance of IO and ST monad code, but it runs the risk of reducing sharing.

Make GHC be more precise about its treatment of bottom (but see also -fno-state-hack). In particular, stop GHC eta-expanding through a case expression, which is good for performance, but bad if you are using seq on partial applications.

Tells GHC to omit all inessential information from the interface file generated for the module being compiled (say M). This means that a module importing M will see only the types of the functions that M exports, but not their unfoldings, strictness info, etc. Hence, for example, no function exported by M will be inlined into an importing module. The benefit is that modules that import M will need to be recompiled less often (only when M's exports change their type, not when they change their implementation).

GHC's optimiser can diverge if you write rewrite rules (Section 7.17, “Rewrite rules ”) that don't terminate, or (less satisfactorily) if you code up recursion through data types (Section 13.2.1, “Bugs in GHC”). To avoid making the compiler fall into an infinite loop, the optimiser carries a "tick count" and stops inlining and applying rewrite rules when this count is exceeded. The limit is set as a multiple of the program size, so bigger programs get more ticks. The -fsimpl-tick-factor flag lets you change the multiplier. The default is 100; numbers larger than 100 give more ticks, and numbers smaller than 100 give fewer.

If the tick-count expires, GHC summarises what simplifier steps it has done; you can use -fddump-simpl-stats to generate a much more detailed list. Usually that identifies the loop quite accurately, because some numbers are very large.

Turn on the static argument transformation.

Turn on call-pattern specialisation.

This option causes all constructor fields which are marked strict (i.e. “!”) to be unboxed or unpacked if possible. It is equivalent to adding an UNPACK pragma to every strict constructor field (see Section 7.16.10, “UNPACK pragma”).

This option is a bit of a sledgehammer: it might sometimes make things worse. Selectively unboxing fields by using UNPACK pragmas might be better. An alternative is to use -funbox-strict-fields to turn on unboxing by default but disable it for certain constructor fields using the NOUNPACK pragma (see Section 7.16.11, “NOUNPACK pragma”).

(Default: 45) Governs the maximum size that GHC will allow a function unfolding to be. (An unfolding has a “size” that reflects the cost in terms of “code bloat” of expanding that unfolding at a call site. A bigger function would be assigned a bigger cost.)

Consequences: (a) nothing larger than this will be inlined (unless it has an INLINE pragma); (b) nothing larger than this will be spewed into an interface file.

Increasing this figure is more likely to result in longer compile times than faster code. The next option is more useful:

(Default: 8) This is the magic cut-off figure for unfolding: below this size, a function definition will be unfolded at the call-site, any bigger and it won't. The size computed for a function depends on two things: the actual size of the expression minus any discounts that apply (see -funfolding-con-discount).