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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

GHC - devs mailing list
#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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

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

GHC - devs mailing list
#13723: Recover gracefully from simplifier tick exhaustion
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.2.1-rc2
      Resolution:                    |             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:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Currently if the limit is exceeded we stop.  It would be better if, when
 the limit was exceeded we refrained from doing the relevant
 transformation.

 That opens up a new debugging mechanism.  If you get a Lint error you can
 binary-chop your way to exactly the transformation that introduced it.

 But it does impose a cost; every transformation needs a conditional, and a
 code-path for not doing the transformation.   We'd need to check what perf
 impact this had.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets