The key tool to use in making your Haskell program run faster are GHC's profiling facilities, described separately in Chapter 5, Profiling. There is no substitute for finding where your program's time/space is really going, as opposed to where you imagine it is going.
Another point to bear in mind: By far the best way to improve a program's performance dramatically is to use better algorithms. Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below.
Another extremely efficient way to make your program snappy
    is to use library code that has been Seriously Tuned By Someone
    Else.  You might be able to write a better
    quicksort than the one in Data.List, but it
    will take you much longer than typing import
    Data.List.
Please report any overly-slow GHC-compiled programs. Since GHC doesn't have any credible competition in the performance department these days it's hard to say what overly-slow means, so just use your judgement! Of course, if a GHC compiled program runs slower than the same program compiled with NHC or Hugs, then it's definitely a bug.
-O or -O2:This is the most basic way to make your program go
          faster.  Compilation time will be slower, especially with
          -O2.
At present, -O2 is nearly
	  indistinguishable from -O.
The LLVM code generator can
			sometimes do a far better job at producing fast code than the native code generator. This is not
			universal and depends on the code. Numeric heavy code seems to show
			the best improvement when compiled via LLVM. You can also experiment
			with passing specific flags to LLVM with the -optlo
			and -optlc flags.  Be careful though as setting these
			flags stops GHC from setting its usual flags for the LLVM optimiser
			and compiler.
Haskell's overloading (using type classes) is elegant, neat, etc., etc., but it is death to performance if left to linger in an inner loop. How can you squash it?
Signatures are the basic trick; putting them on
                exported, top-level functions is good
                software-engineering practice, anyway.  (Tip: using
                -fwarn-missing-signatures can help enforce good
                signature-practice).
The automatic specialisation of overloaded
                functions (with -O) should take care
                of overloaded local and/or unexported functions.
SPECIALIZE pragmas:Specialize the overloading on key functions in your program. See Section 7.18.8, “SPECIALIZE pragma” and Section 7.18.9, “SPECIALIZE instance pragma ”.
A low-tech way: grep (search) your interface
                files for overloaded type signatures.  You can view
                interface files using the
                --show-iface option (see Section 4.7.7, “Other options related to interface files”).
% ghc --show-iface Foo.hi | egrep '^[a-z].*::.*=>'
and, among other things, lazy pattern-matching is your enemy.
(If you don't know what a “strict function” is, please consult a functional-programming textbook. A sentence or two of explanation here probably would not do much good.)
Consider these two code fragments:
f (Wibble x y) =  ... # strict
f arg = let { (Wibble x y) = arg } in ... # lazy
The former will result in far better code.
A less contrived example shows the use of
          cases instead of lets
          to get stricter code (a good thing):
f (Wibble x y)  # beautiful but slow
  = let
        (a1, b1, c1) = unpackFoo x
        (a2, b2, c2) = unpackFoo y
    in ...
f (Wibble x y)  # ugly, and proud of it
  = case (unpackFoo x) of { (a1, b1, c1) ->
    case (unpackFoo y) of { (a2, b2, c2) ->
    ...
    }}
It's all the better if a function is strict in a single-constructor type (a type with only one data-constructor; for example, tuples are single-constructor types).
If your datatype has a single constructor with a
          single field, use a newtype declaration
          instead of a data declaration.  The
          newtype will be optimised away in most
          cases.
Don't guess—look it up.
Look for your function in the interface file, then for
          the third field in the pragma; it should say
          Strictness: <string>.  The
          <string> gives the strictness of
          the function's arguments: see 
          the GHC Commentary for a description of the strictness notation.
          
For an “unpackable”
          U(...) argument, the info inside tells
          the strictness of its components.  So, if the argument is a
          pair, and it says U(AU(LSS)), that
          means “the first component of the pair isn't used; the
          second component is itself unpackable, with three components
          (lazy in the first, strict in the second \&
          third).”
If the function isn't exported, just compile with the
          extra flag -ddump-simpl; next to the
          signature for any binder, it will print the self-same
          pragmatic information as would be put in an interface file.
          (Besides, Core syntax is fun to look at!)
INLINEd (esp. monads):Placing INLINE pragmas on certain
          functions that are used a lot can have a dramatic effect.
          See Section 7.18.5.1, “INLINE pragma”.
export list:If you do not have an explicit export list in a module, GHC must assume that everything in that module will be exported. This has various pessimising effects. For example, if a bit of code is actually unused (perhaps because of unfolding effects), GHC will not be able to throw it away, because it is exported and some other module may be relying on its existence.
GHC can be quite a bit more aggressive with pieces of code if it knows they are not exported.
(The form in which GHC manipulates your code.)  Just
          run your compilation with -ddump-simpl
          (don't forget the -O).
If profiling has pointed the finger at particular
          functions, look at their Core code.  lets
          are bad, cases are good, dictionaries
          (d.<Class>.<Unique>) [or
          anything overloading-ish] are bad, nested lambdas are
          bad, explicit data constructors are good, primitive
          operations (e.g., eqInt#) are
          good,…
Putting a strictness annotation ('!') on a constructor field helps in two ways: it adds strictness to the program, which gives the strictness analyser more to work with, and it might help to reduce space leaks.
It can also help in a third way: when used with
	  -funbox-strict-fields (see Section 4.10.2, “-f*: platform-independent flags”), a strict field can be unpacked or
	  unboxed in the constructor, and one or more levels of
	  indirection may be removed.  Unpacking only happens for
	  single-constructor datatypes (Int is a
	  good candidate, for example).
Using -funbox-strict-fields is only
	  really a good idea in conjunction with -O,
	  because otherwise the extra packing and unpacking won't be
	  optimised away.  In fact, it is possible that
	  -funbox-strict-fields may worsen
	  performance even with
	  -O, but this is unlikely (let us know if it
	  happens to you).
When you are really desperate for speed, and you want to get right down to the “raw bits.” Please see Section 7.2.1, “Unboxed types” for some information about using unboxed types.
Before resorting to explicit unboxed types, try using
	  strict constructor fields and
	  -funbox-strict-fields first (see above).
	  That way, your code stays portable.
foreign import (a GHC extension) to plug into fast libraries:This may take real work, but… There exist piles of massively-tuned library code, and the best thing is not to compete with it, but link with it.
Chapter 8, Foreign function interface (FFI) describes the foreign function interface.
Floats:If you're using Complex, definitely
          use Complex Double rather than
          Complex Float (the former is specialised
          heavily, but the latter isn't).
Floats (probably 32-bits) are
          almost always a bad idea, anyway, unless you Really Know
          What You Are Doing.  Use Doubles.
          There's rarely a speed disadvantage—modern machines
          will use the same floating-point unit for both.  With
          Doubles, you are much less likely to hang
          yourself with numerical errors.
One time when Float might be a good
          idea is if you have a lot of them, say
          a giant array of Floats.  They take up
          half the space in the heap compared to
          Doubles.  However, this isn't true on a
          64-bit machine.
UArray)GHC supports arrays of unboxed elements, for several
	  basic arithmetic element types including
	  Int and Char: see the
	  Data.Array.Unboxed library for details.
	  These arrays are likely to be much faster than using
	  standard Haskell 98 arrays from the
	  Data.Array library.
If your program's GC stats
          (-S RTS option) indicate that it's
          doing lots of garbage-collection (say, more than 20%
          of execution time), more memory might help—with the
          -M<size> or
          -A<size> RTS options (see Section 4.17.3, “RTS options to control the garbage collector”).