[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200

[GHC]

#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