-O vs. -O2

Simon Marlow marlowsd at gmail.com
Mon May 10 05:27:00 EDT 2010

On 10/05/2010 03:43, Roman Leshchinskiy wrote:
> On 09/05/2010, at 07:50, Duncan Coutts wrote:
>> On Wed, 2010-05-05 at 21:24 +1000, Roman Leshchinskiy wrote:
>>> Whenever I do cabal sdist on one of my projects, I get this
>>> warning:
>>> Distribution quality warnings: 'ghc-options: -O2' is rarely
>>> needed. Check that it is giving a real benefit and not just
>>> imposing longer compile times on your users.
>>> This finally got me curious and I did a nofib run to compare -O
>>> to -O2. The results are below (this is with the current HEAD).
>>> Is there a real-world example of -O2 causing significantly
>>> longer compile times without providing a real benefit? If not,
>>> would it perhaps make sense for Cabal to use -O2 by default or
>>> even for GHC to make the two flags equivalent?
>> It should be -O1 for default/balanced optimisations and -O2 for
>> things involving a bigger tradeoff in terms of code size or compile
>> time. so any optimisations in -O2 that GHC HQ believe are a
>> no-brainer for the majority of packages should be moved into -O1.
> Unless I'm mistaken, the only difference between -O1 and -O2 are
> SpecConstr and LiberateCase. These are quite heavily constrained by
> default (e.g., SpecConstr will not specialise big functions and will
> not generate more than 3 specialisations for smaller ones).

I'd like to keep a distinction between -O1 and -O2, but I agree with you 
that we could probably look at how the optimisations are currently 
distributed between the options.  We could probably also add a -O3 that 
turns up various thresholds for people who don't mind generating larger 

-O1 is supposed to represent good value for compile-time.  It gets all 
the low-hanging fruit.  I use -O in my development builds, whereas it 
makes sense for Cabal to turn on -O2 by default and for us to use -O2 
for the nightly builds and when building GHC distributions (we already 
do this).


More information about the Glasgow-haskell-users mailing list