Go to the first, previous, next, last section, table of contents.

`-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-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'.

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:

(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.)
(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.
(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).
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 anymore... Sigh.)

Go to the first, previous, next, last section, table of contents.