#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