[GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks

[GHC]

#12150: Compile time performance degradation on code that uses undefined/error with
CallStacks
-------------------------------------+-------------------------------------
        Reporter:  thomie            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.2
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10844            |  Differential Rev(s):  Phab:D3753
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"33452dfc6cf891b59d63fa9fe138b18cbce4df81/ghc"
 33452dfc/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="33452dfc6cf891b59d63fa9fe138b18cbce4df81"
 Refactor the Mighty Simplifier

 Triggered by #12150, and the knock-on effects of join points, I did a
 major refactoring of the Simplifier.  This is a big patch that change
 a lot of Simplify.hs: I did a lot of other re-organisation.

 The main event
 ~~~~~~~~~~~~~~
 Since the dawn of time we have had
   simplExpr :: SimplEnv -> InExpr -> SimplCont
             -> SimplM (SimplEnv, OutExpr)

 What's that SimplEnv in the result?  When simplifying an expression the
 simplifier add floated let-bindings to the SimplEnv, extending the
 in-scope set appropriately, and hence needs to resturn the SimplEnv at
 the end.  The mode, flags, substitution in the returned SimplEnv were
 all irrelevant: it was just the floating bindings.

 It's strange to accumulate part of the /result/ in the /environment/
 argument!  And indeed its leads to all manner of mysterious calls to
 zapFloats and transferring of floats from one SimplEnv to another.
 It got worse with join points, so I finally bit the bullet and refactored.
 Now we have
   simplExpr :: SimplEnv -> InExpr -> SimplCont
             -> SimplM (SimplFloats, OutExpr)
   -- See Note [The big picture]
 and the SimplEnv no longer has floats in it.  The code is no shorter,
 but it /is/ easier to understand.

 Main changes

 * Remove seLetFloats field from SimplEnv

 * Define new data type SimplFloats, and functions over it

 * Change the types of simplExpr, simplBind, and their many variants,
   to follow the above plan

 Bottoming bindings
 ~~~~~~~~~~~~~~~~~~
 I made one other significant change in SimplUtils (not just refactoring),
 related to Trac #12150 comment:16.  Given
   x = <rhs>
 where <rhs> turns out to be a bottoming expression, propagate that
 information to x's IdInfo immediately.  That's always good, because
 it makes x be inlined less (we don't inline bottoming things), and
 it allows (case x of ...) to drop the dead alterantives immediately.
 Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
 calls CoreArity.findRhsArity, which already does simple bottom analysis.
 So we are generating the information; all we need do is to atach the
 bottoming info to the IdInfo.

 See Note [Bottoming bindings]

 Smaller refactoring
 ~~~~~~~~~~~~~~~~~~~
 * Rename SimplifierMode to SimplMode
 * Put DynFlags as a new field in SimplMode, to make fewer
   monadic calls to getDynFlags.
 * Move the code in addPolyBind into abstractFloats
 * Move the "don't eta-expand join points" into tryEtaExpandRhs
 }}}

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