GHC: Policy on -O flags?

Andreas Klebinger klebinger.andreas at
Tue Aug 27 16:10:30 UTC 2019

Hello ghc-devs and haskell users.

I'm looking for opinions on when an optimization should be enabled by

-O is currently the base line for an optimized build.
-O2 adds around 10-20% compile time for a few % (around 2% if I remember
correctly) in performance for most things.

The question is now if I implement a new optimization, making code R%
faster but slowing
down the compiler down by C% at which point should an optimization be:

* Enabled by default (-O)
* Enabled only at -O2
* Disabled by default

Cheap always beneficial things make sense for -O
Expensive optimizations which add little make sense for -O2

But where exactly is the line here?
How much compile time is runtime worth?

If something slows down the compiler by 1%/2%/5%
and speeds up code by 0.5%/1%/2% which combinations make sense
for -O, -O2?

Can there even be a good policy with the -O/-O2 split?

Personally I generally want code to either:
* Typecheck/Run at all (-O0, -fno-code, repl)
* Not blow through all my RAM when adding a few Ints while developing: -O ?
* Make a reasonable tradeoff between runtime/compiletime: -O ?
* Give me all you got: -O2 (-O99999)

The use case for -O0 is rather clear, so is -O2.
But what do people consider the use case for -O

What trade offs seem acceptable to you as a user of GHC?

Is it ok for -O to become slower for faster runtimes? How much slower?
Should all new improvements which might slow down compilation
be pushed to -O2?

Or does an ideal solution add new flags?
Tell me what do you think.

Andreas Klebinger

More information about the ghc-devs mailing list