"Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200

This is perhaps the same bug as #10527 (closed) but I'm not sure, as it goes away with a modest bump to -fsimpl-tick-factor.

I'm developing a library and am seeing this when I go to compile a small hello-world executable.

<no location info>:
    ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-linux):
	Simplifier ticks exhausted
  When trying UnfoldingDone $fMonadIdentity_$c>>=
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  To see detailed counts use -ddump-simpl-stats
  Total ticks: 6642

If I remove the INLINE from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error).

It also compiles with -fsimpl-tick-factor=200.

Previously on 7.10.1 I got the same error in a different part of my code (the benchmark suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of my library repo, but it's not a small test case.

Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump -fsimpl-tick-factor to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions), and how do I know whether this won't blow up in the same way for users anyway?

changed weight to 5

added Tbug Trac import labels

changed the description

Trac metadata

Trac field	Value
Related	#10527 (closed) → #5539 (closed), #8319, #10527 (closed)

It's not a bug in your code. It just indicates that GHC is doing an unusual amount of work per line of (your original) code. That's interesting but probably not your fault.

It can indicate that you (or a library you are using) are inlining too much code, perhaps (but not necessarily) unproductively so.

Occasionally it can be an indication that you've tripped over a well-known bug in GHC that makes things inline forever (#11240 (closed), #8833 (closed), #3872, #5400, #5448, #5722, #7057, #7369 (closed), #9235).

Reporting it is good, especially if we can reproduce it; it can also mean that GHC is working harder than it should.

Thanks, Simon. I'm afraid this won't be very helpful but I've pushed a branch of my library which exhibits the error here (I'll keep this around while this issue is open), at commit 18b99b6:

https://github.com/jberryman/unagi-bloomfilter/tree/simplifier-ticks-exhausted-bug-11263

It includes frozen dependency versions. You can trigger the bug with: cabal configure -fdev && cabal build.

After cabal install hashabler, the problem is reproducible with this small program and a simple tick factor as high as 130:

Main.hs:

module Main where

import Bloom

main = do
    key <- undefined
    lookup_ key `seq` return ()

Bloom.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..):

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.

Attached file Bloom.hs ($1169).

Bloom with relevant parts of Hashabler inlined

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → CompileTimePerformance

Also in cabal install diagrams:

[2 of 5] Compiling Graphics.Svg.Core ( src/Graphics/Svg/Core.hs, dist/build/Graphics/Svg/Core.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.4 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone base:Foreign.Storable.$fStorableWord8_$cpokeByteOff{v r2gn} [gid]
    To increase the limit, use -fsimpl-tick-factor=N (default 100)
    If you need to do this, let GHC HQ know, and what factor you needed
    To see detailed counts use -ddump-simpl-stats
    Total ticks: 34200

(On Ubuntu server 15.10).

Output from -ddump-simpl-stats is attached as diagrams-dump-simpl-stats.txt.

Attached file diagrams-dump-simpl-stats.txt (download).

mentioned in issue #12967 (closed)

added Pnormal label