[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2

[GHC]

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC
8.2
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:  rwbarton
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             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):  Phab:D3399,
       Wiki Page:                    |  Phab:D3400
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 Replying to [comment:14 simonpj]:
 > PS: you may then be able to get rid of the call to `coreBindsSize` in
 `SimplCore`.  If so, that would be good: faster compilation!  Worth
 trying... it might I suppose show up another leak currently patched by
 `coreBindsSize`.

 The input core program size is used to bound the number of simplifier
 ticks so we can't remove the call to `coreBindsSize` entirely without
 affecting the behavior of the simplifier. I'm not sure whether we could
 make do with a more crude estimate of program size.

 However, `coreBindsSize` currently goes out of its way to force a lot of
 structure (like `seqBinds` does) that is not needed to compute the Core
 program size. So an easy intermediate option is to just remove all the
 extra `seq`s from `coreBindsSize`. This still leaves a lot less work than
 `coreBindsSize` does currently and forcing the main program body may be
 useful.

 I almost have this working but in order to fix another space leak I had to
 make another similar change of
 {{{#!hs
 simplExpr env expr = simplExprC env expr (mkBoringStop expr_out_ty)
   where
     expr_out_ty :: OutType
     expr_out_ty = substTy env (exprType expr)
 }}}
 to
 {{{#!hs
 simplExpr env expr
   = do { expr_out_ty <- simplType env (exprType expr)
        ; simplExprC env expr (mkBoringStop expr_out_ty) }
 }}}
 However, this also produces a lot of warnings like
 {{{
 exprType TYPE: ModuleName
 }}}
 which seem to be from calling `simplExpr` on a `Type t`. Is it a bug that
 that happens in the first place? What is the best way to handle this? I
 get another smal improvement in space and time from this change so I'm
 hoping this is easy to finish off. Please advise!

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