> I need an advice on -O, INLINE, NOINLINE usage for ghc-4.01 and
> highers.
> My program contains many short definitions, like, say,
>
> bound = 2^20 :: Integer
>
> lc :: C a => Pol a -> a
> lc (Pol ms _) = fst (head ms)
>
> - also many of them are the class operation definitions.
>
> They need to be INLINE-d - into any piece of optimised code.
> But this implies the neccessity of -O compilation key for the whole
> given module. Right?
Yes, you need -O to take advantage of inter-module inlining.
> And this module, it often contains also the large parts that do not
> need -O. Re-arranging between the modules specially for -O is very
> un-desirable.
You should either compile the whole lot with -O, or not at all. Generally
you only use -O when speed is really an issue, or when building a binary
that you're going to install or release.
> The impression of the earlier versions was that -O -ing *everything*
> often leads to worse run-time cost code - right?
If it does, that's a bug. There's only one situation I can think of where
you don't want to use -O: compiling a Happy-generated parser (GHC tends to
take a long time with -O turned on, and doesn't manage to optimise the code
very much).
> So i think of the decision:
> to compile all modules with -O
> and mark with {-# NOILINE ...#-} the chosen parts to avoid
> un-neccessary inlining.
> What is your advice?
The default should do the right thing, i.e. you don't need to add NOINLINE
pragmas. Inlining doesn't really hurt, the worst that can happen is that
the code gets a big larger, and GHC has quite a bit of intelligence built in
to its inliner to avoid unnecessary inlinings and hence code bloat.
> And it looks like ghc-4.01 -c -O ignores NOINLINE.
Do you have an example? It works fine as far as I can tell.
Bottom line:
- just compile the whole lot with -O
- for functions you really want to inline, but GHC is
being a bit conservative, add an INLINE pragma.
- specialise overloaded stuff using SPECIALISE
- consider using strictness annotations on constructor
fields (not always a good idea) and unboxed types
(usually a good idea, but hard to work with)
Cheers,
Simon
--
Simon Marlow
Microsoft Research Ltd., Cambridge, U.K.
