-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
code.
-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).
Cheers,
Simon
More information about the Glasgow-haskell-users
mailing list