GHC lazy eval optimization bug

Chris Kuklewicz haskell at
Sun Feb 3 15:34:41 EST 2008

Thanks Don.  That is the issue.  I just added this comment/request to trac #1168:

> This just came up on the mailing list again.  The program was slow unless
> (-fno-state-hack) was used.
> Is it possible to have GHC emit a warning (as part of -Wall) to let the use
> know that GHC is applying a potentially risky simplification?

I had tried -Wall before you told me about -fno-state-hack.  If -Wall had warned 
me about the hack then I could have understood the problem without a frequently 
asked question to the list.


Don Stewart wrote:
> haskell:
>> I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4) 
>> Leopard.
>> It performs correctly, lazily keeping 'primes' for all 4 repetitions, when 
>> using "ghc -Onot" but the the doSlow fails to retain 'primes' when 
>> compiling with "ghc -O" and "ghc -O2"
> Sounds like the known issue of the simplifier eta-expanding `State#`
> lambdas on purpose, which is good for IO, but risks re-computation. The
> 'calendar' nofib program exhibits this, iirc.
> See,
> Try compiling with:
>     -fno-state-hack
> -- Don

More information about the Glasgow-haskell-users mailing list