[GHC] #9020: Massive blowup of code size on trivial program

[GHC]

#9020: Massive blowup of code size on trivial program
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                   Owner:
            Type:  bug               |                  Status:  closed
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.2
      Resolution:  fixed             |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |  perf/compiler/T9020
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by nomeata):

 > Rather than muttering about PAPs, perhaps we can simply switch off eta-
 expansion altogether under these conditions?

 With "these conditions",  do you mean "gentle phase" a.k.a. "sm_inline =
 False"? If so, then that is precisely what I am proposing:
 {{{
         -- initial simplify: mk specialiser happy: minimum effort please
     simpl_gently = CoreDoSimplify max_iter
                        (base_mode { sm_phase = InitialPhase
                                   , sm_names = ["Gentle"]
                                   , sm_rules = rules_on   -- Note [RULEs
 enabled in SimplGently]
                                   , sm_inline = False
                                   , sm_case_case = False
                                   , sm_eta_expand = False}) -- This line
 was added
                           -- Don't do case-of-case transformations.
                           -- This makes full laziness work better
 }}}

 We still need to distinguish between `sm_inline` and `sm_eta_expand`, as
 the former is always on in the `base_mode`, while the second one depends
 on `Opt_DoLambdaEtaExpansion`.

 (Which means that this flag isn’t correctly named, as it affects all eta-
 expansion, not just lambda-eta-expansion.)

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