[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
GHC
ghc-devs at haskell.org
Mon Jan 18 15:10:36 UTC 2016
#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
-------------------------------------+-------------------------------------
Reporter: jberryman | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #10527 #5539 | Differential Rev(s):
#8319 |
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by thomie):
After `cabal install hashabler`, the problem is reproducible with this
small program and a simple tick factor as high as `130`:
Main.hs:
{{{#!hs
module Main where
import Bloom
main = do
key <- undefined
lookup_ key `seq` return ()
}}}
Bloom.hs:
{{{#!hs
module Bloom where
import Data.Hashabler
{-# INLINE lookup_ #-}
lookup_ :: SipKey -> Hash128 Int
lookup_ key = siphash128 key 1
}}}
{{{
$ ghc-7.10.3 Main.hs -O -fforce-recomp -fsimpl-tick-factor=130 # 135=ok
...Simplifier ticks exhausted...
}}}
Some observations:
* Putting all code in a single module doesn't trigger the problem
* This doesn't trigger the problem (I don't understand why not doing `key
<- undefined` makes a difference..):
{{{#!hs
main = lookup_ undefined `seq` return ()
}}}
* ghc-8.0.1 accepts the program with a tick factor as low as `85`. Did
something change?
I will attach a version of `Bloom.hs` with `hashabler` inlined.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11263#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list