Opened 3 years ago

Last modified 2 years ago

#11263 new bug

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

Reported by: jberryman Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.3
Keywords: Inlining Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: #10527 #5539 #8319 Differential Rev(s):
Wiki Page:

Description (last modified by jberryman)

This is perhaps the same bug as #10527 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?

Attachments (2)

Bloom.hs (5.7 KB) - added by thomie 3 years ago.
Bloom with relevant parts of Hashabler inlined
diagrams-dump-simpl-stats.txt (74.4 KB) - added by stusmith 2 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 3 years ago by jberryman

comment:2 Changed 3 years ago by jberryman

Description: modified (diff)

comment:3 Changed 3 years ago by jberryman

comment:4 Changed 3 years ago by simonpj

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, #8833, #3872, #5400, #5448, #5722, #7057, #7369, #9235).

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

comment:5 Changed 3 years ago by jberryman

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.

comment:6 Changed 3 years ago 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:

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.

Changed 3 years ago by thomie

Attachment: Bloom.hs added

Bloom with relevant parts of Hashabler inlined

comment:7 Changed 3 years ago by simonpj

Type of failure: None/UnknownCompile-time performance bug

comment:8 Changed 2 years ago by stusmith

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.

Changed 2 years ago by stusmith

comment:9 Changed 2 years ago by mpickering

Keywords: Inlining added
Note: See TracTickets for help on using tickets.