[GHC] #13723: Recover gracefully from simplifier tick exhaustion

[GHC]

#13723: Recover gracefully from simplifier tick exhaustion
-------------------------------------+-------------------------------------
           Reporter:  dfeuer         |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:  8.4.1
          Component:  Compiler       |           Version:  8.2.1-rc2
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Compile-time
  Unknown/Multiple                   |  crash or panic
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Currently, we have just one tick limit. If the simplifier runs out of
 ticks, GHC simply gives up and exits. But that shouldn't ''really'' be
 necessary. In a more ideal world, we'd have two or even three tick limits
 for different kinds of transformations. For example, there are

 === Transformations that must be performed before `CorePrep` ===

 I hope that we can give a hard upper bound on how many ticks we need to
 perform these for a given program size. If that limit is exceeded, then we
 should report a bug.

 === Transformations that always reduce program size ===

 If a transformation always reduces program size, we can always perform it,
 even if we're otherwise out of ticks. This includes, at least, beta
 reduction without duplication. While `RULES` are generally wild, it should
 be safe to apply rules that reduce code size ''immediately''. For example,

 {{{#!hs
 foldr c n (build f) ==> f c n
 }}}

 is always fine. These transformations can share a tick limit with the
 mandatory transformations mentioned above.

 === Transformations that never increase program size ===

 We can be generous with these, but need some limit.

 === Transformations that may increase program size ===

 These need the harshest limit, of course, but probably not (much?) harsher
 than what we currently have.

 ----

 The idea is that even if one tick limit is exceeded, the "higher priority"
 transformations can be allowed to continue anyway. Exceeding tick limits
 for most transformations would lead to a warning, rather than an error.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13723>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler