#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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jberryman: Old description:

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 test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the 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)?

New description: 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? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11263#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11263#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#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: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11263#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by stusmith): * Attachment "diagrams-dump-simpl-stats.txt" added. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11263 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler