`-f*': platform-independent flags

Flags can be turned off individually. (NB: I hope you have a good reason for doing this....) To turn off the `-ffoo' flag, just use the `-fno-foo' flag. So, for example, you can say `-O2 -fno-strictness', which will then drop out any running of the strictness analyser.

The options you are most likely to want to turn off are: `-fno-update-analysis' [because it is sometimes slow], `-fno-strictness' (strictness analyser [because it is sometimes slow]), `-fno-specialise' (automatic specialisation of overloaded functions [because it makes your code bigger]) [US spelling also accepted], and `-fno-foldr-build' [because no-one knows what Andy Gill made it do].

Should you wish to turn individual flags on, you are advised to use the `-Ofile' option, described above. Because the order in which optimisation passes are run is sometimes crucial, it's quite hard to do with command-line options.

Here are some "dangerous" optimisations you might want to try:

`-funfolding-creation-threshold<n>':

(Default: 30) By raising or lowering this number, you can raise or lower the amount of pragmatic junk that gets spewed into interface files. (An unfolding has a "size" that reflects the cost in terms of "code bloat" of expanding that unfolding in another module. A bigger Core expression would be assigned a bigger cost.)

`-funfolding-use-threshold<n>':

(Default: 3) By raising or lowering this number, you can make the compiler more or less keen to expand unfoldings. OK, folks, these magic numbers `30' and `3' are mildly arbitrary; they are of the "seem to be OK" variety. The `3' is the more critical one; it's what determines how eager GHC is about expanding unfoldings.

`-funfolding-override-threshold<n>':

(Default: 8) [Pretty obscure] When deciding what unfoldings from a module should be made available to the rest of the world (via this module's interface), the compiler normally likes "small" expressions. For example, if it sees `foo = bar', it will decide that the very small expression `bar' is a great unfolding for `foo'. But if `bar' turns out to be `(True,False,True)', we would probably prefer that for the unfolding for `foo'. Should we "override" the initial small unfolding from `foo=bar' with the bigger-but-better one? Yes, if the bigger one's "size" is still under the "override threshold." You can use this flag to adjust this threshold (why, I'm not sure).

`-fliberated-case-threshold<n>':

(Default: 12) [Vastly obscure: NOT IMPLEMENTED YET] "Case liberation" lifts evaluation out of recursive functions; it does this by duplicating code. Done without constraint, you can get serious code bloat; so we only do it if the "size" of the duplicated code is smaller than some "threshold." This flag can fiddle that threshold.

`-fsemi-tagging':

This option (which does not work with the native-code generator) tells the compiler to add extra code to test for already-evaluated values. You win if you have lots of such values during a run of your program, you lose otherwise. (And you pay in extra code space.) We have not played with `-fsemi-tagging' enough to recommend it. (For all we know, it doesn't even work in 0.26. Sigh.)