[GHC] #13282: Introduce fast path through simplifier for static bindings

[GHC]

#13282: Introduce fast path through simplifier for static bindings
-------------------------------------+-------------------------------------
           Reporter:  bgamari        |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Compile-time
  Unknown/Multiple                   |  performance bug
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 It's not uncommon for early simplifier runs to float out a large number of
 "static data" bindings from a user program to the top-level. Here we will
 consider a top-level binding to be "static" if its RHS consists of a data
 constructor applied to zero or more other static bindings. This floating
 is quite helpful as static top-levels are represented easily as static
 code in object code. It also opens an interesting possibility: we know
 (with a few potential caveats discussed later) no further simplification
 of these bindings is possible.

 However, the simplifier currently does not take advantage of this latter
 fact: currently the simplifier will dutifully rebuild all bindings on
 every iteration. This work is wasted effort.

 I think it would be helpful to track the "static-ness" of top-level
 bindings and teach the simplifier and various analyses to ignore bindings
 so-marked.

 Also, there is one caveat here: it is currently possible for users to
 write rules whose LHSs are headed by a data constructor. This means that
 further simplification of the bindings which we deemed above as "static"
 **is** possible. There are two ways of dealing with this,

 a. Forbidding data cons in the head of a RULE's LHS
 b. Check the rule-base for matching rules matching a datacon as "static"

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