[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:  (none)
            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, Phab:D3421
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 After writing comment:28 I got the validate results from Phab:D3421 which
 show a ~75% increase in allocations when compiling
 [https://raw.githubusercontent.com/ghc/ghc/master/testsuite/tests/perf/compiler/T5631.hs
 T5631] which involves many very large types; the only change in that
 commit being to the `App fun arg` case of `simplExprF1`.

 I see that the `sc_arg_ty` is (almost) always used because it occurs as
 the type a function is applied to in the output program. But `sc_hole_ty`
 is only ever used via `contHoleType` and put in a `mkBoringStop`. There is
 even a Note `[The hole type in ApplyToTy]` which suggests that evaluating
 `sc_hole_ty` eagerly would be bad.

 I tried going back to using `substTy` for the `sc_hole_ty` field, while
 using `simplType` for the `sc_arg_ty` field. This still avoids the space
 leak when compiling `DynFlags` and also avoids the regression in T5631. So
 it seems to be the right thing to do.

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