Re: GHC: Policy on -O flags?

2019-08-27 Thread Sebastian Graf
Hi, I used to think that the policy for being eligible for -O1 is that C must be non-positive, e.g. that the compile times don't suffer at all. Everything beyond that (well, given that R is positive) should be -O2 only. There's precedent at least for Late Lambda Lifting (which is only run for

Re: [Haskell-cafe] GHC: Policy on -O flags?

2019-08-27 Thread Matthew Pickering
`-O2` is not a very rationally considered flag from what I understand. It only enables `-fspec-constr` and `-fliberate-case`. The later also triggers another simplification pass. `-fspec-constr` is quite limited as it only works in the definition module. I have never trusted it to optimise my

Re: GHC: Policy on -O flags?

2019-08-27 Thread Brandon Allbery
I think at first you just give it a -f flag, and let experience determine whether it should be part of -O or -O2. On Tue, Aug 27, 2019 at 12:10 PM Andreas Klebinger wrote: > Hello ghc-devs and haskell users. > > I'm looking for opinions on when an optimization should be enabled by > default. >

GHC: Policy on -O flags?

2019-08-27 Thread Andreas Klebinger
Hello ghc-devs and haskell users. I'm looking for opinions on when an optimization should be enabled by default. -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